© 



3 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(£) Publication number: 



0 534 466 A2 



©. 



EUROPEAN PATENT APPLICATION 



© Application number: 92116474.5 
© Date of filing: 25.09.92 

® Priority: 27.09.91 US 767230 

© Date of publication of application: 
31.03.93 Bulletin 93/13 



© Designated Contracting States: 

AT BE CH DE DK ES FR GB GR IE IT LI LU MC 
NL PT SE 



eg 
< 

to 

CO 

in 



© fntci 5 : G06F 15/40, G06F 15/403 



© Applicant: BMC Software, Inc. 

1 Sugar Creek Boulevard Center Suite 500 
Sugarland Texas 77478(US) 

© Inventor: Olson, Jack E. 
9800 Vista View Drive 
Austin, Texas 78750(US) 
Inventor: Elliott, Linda C. 
1602 Springer Lane 
Austin, Texas 78758(US) 



© Representative: Altenburg, Udo, Dipl.-Phys. et 
al 

Patent- und Rechtsanwalte 
Bardehle-Pagenberg-Dost-Altenburg 
Frohwltter-Geissler & Partner Postfach 86 06 
20 

W-8000 Munchen 86 (DE) 

i : 



© Change definition language for computer database system. 

© A database application implemented on a computer includes a generic database management product 
(software) such as IBM DB2 along with a catalog defining the way the data itself is stored. The catalog is a 
definition of the tables, indexes, views, user authorizations, etc., that specify a user's particular application of the 
database management system. Access to the database via the catalog uses a structured query language or 
(SQL) which provides a way of expressing statements in a high-level language so the user will not be burdened 
with writing code to access the data itself. The structured query language provides statements for defining 
tables indexes, views, etc.. to be incorporated into the catalog. A database application (to fit a user s business) 
is generated and updated in a number of phases, such as design, development, test and production and in each 
one of these phases a facility exists for making alterations in the database definition (catalog), all of which make 
use of SQL to implement the changes. According to a feature of the invention, a change definition language 
(CDL) is provided which is an extension of (and in the general format of) the structured query language. The 
change definition language allows all important alterations to be described, as changes to an existing definition, 
for example, and may be used by all phases of the development cycle. The CDL statements do not make the 
changes directly in the catalog, but instead work through SQL and another intermediate mechanism such as DB2 
ALTER tailored to make changes using SQL. The changes expressed in CDL may be migrated to downstream 
phases and fed back to earlier phases by use of a batch of change statements expressed in CDL. 
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This invention relates to computer database systems, and more particularly to a language for a method 
of making changes to a definition of a relational database system. 

A database system operating in an environment such as that provided by IBM's DATABASE 2 (DB2) 
computer software system commonly takes the form of a relational database product which appears to a 
5 user as a set of user-defined tables. A table is a set of columns and rows, where each column has a user- 
selected name and datatype, and each row is a record of data values entered for the columns. This type of 
database product, when fully developed and operating on a computer, includes a catalog (or dictionary) 
which defines these tables, as well as indexes and views of the tables, and relationships between them, 
plus the data itself entered by users. A structured query language, referred to as SQL, is employed to 
70 access the data, and is also used to define the form of the database, i.e., describe the tables, and describe 
indexes and views of the tables and other objects of the database. This structured query language is a high 
level programming language specifically designed for the database product, and permits a user to access 
or define elements without resort to a lower-level language or assembly. The statements of SQL are limited, 
however, and so other programming tools and languages are used, particularly in design and development 
75 phases of application definition. 

After such a database system has been initially developed (e.g., by a DB2 customer's in-house 
programmers), the system is frequently subjected to an on-going series of changes as it is upgraded, 
debugged, expanded, etc. A commercially-available product useful for generating these changes is a 
product called "DB2 ALTER," sold by BMC Software, Inc.. the assignee of this invention; this product 
20 functions to allow a user to describe changes in an interactive way (at a terminal), then these changes are 
'implemented by using SQL to make changes in the database definition itself. Generally, a product such as 
DB2 ALTER effects changes by producing a sequence of operations expressed in SQL and other functional 
languages for unloading a database, wiping out (dropping) a part of the catalog, rebuilding a new part of the 
catalog to replace that which was dropped, then restructuring the data according to the revised catalog. 
25 Commercially available products providing features analogous to DB2 ALTER include RC MIGRATE, by 
Platinum Technology of Lombard, Illinois, PROALTER PLUS by On-Line Software of Fort Lee, New Jersey, 
TRANSRELATE by Compuware, and a product made by Goal Systems International of Columbus, Ohio. 

A database system for a particular application may be created and debugged by separate teams of 
programmers in a large organization, and these teams may use incompatible tools. A design team makes 
30 an initial design, often employing a computer-aided software engineering (CASE) tool, (for example, a 
commercially-available Bachman tool) and the database definition is passed on in the form of a set of SQL 
statements to a development team which has the responsibility of generating a production version of the 
database. The development team, in changing the definition for more fully tailoring the application to the 
customer's intent, may employ a different tool, such as DB2 ALTER, or another programming language, for 
35 its own efficiency or convenience. The developers may then turn the revised version of the database over to 
a testing facility, where testing and debugging result in additional changes; these changes may be 
implemented again in DB2 ALTER. Finally, the database is released to production use, and the team which 
maintains the software for the production operation may make performance-enhancing changes in the way 
the data is physically stored, and other changes as a result of factors discovered by data-to-day users 
40 entering data or evaluating reports generated by the database system. Meanwhile, the design team is 
generating updated versions of the system, adding features and incorporating changes as a result of 
changes in the business, hardware additions, etc., and these updated versions pass through the same 
series of phases - development, test and production. The downstream phases must employ the updated, 
revised version of the system, but yet will want to keep the revisions they have made in the previous 
45 version. All of the changes made at any phase must therefore be migrated forward to downstream users, 
and often also fed back to earlier phases, and this must be done in an efficient manner. 

Since the design and development people are often using design tools and languages in generating the 
database definition, which may be different from that of the production-level programmers, and the definition 
and changes must be implemented in a specific mechanism such as SQL for IBM DB2, a problem has 
so existed in passing changes from design and development to production, and integrating production-level 
changes into a design and development environment. Only by extensive hand-entry of change lists, and 
comparisons of lengthy descriptions, have these types of interaction been achievable. 

In accordance with one embodiment of the invention, a database application implemented on a 
computer includes a generic database management product (software) along with a catalog defining the 
55 way the data itself is stored. In a particular embodiment, the database system operates in the IBM DB2 
environment. The catalog is a definition of the tables, indexes, views, user authorizations, etc.. that specify a 
user's particular application of the database management system. Access to the database via the catalog 
uses a structured query language. A structured query language (SQL) provides a way of expressing 
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statements in a high-level language so the user will not be burdened with writing code to access the data 
itself. The structured query language provides statements for defining tables, indexes, views, etc.. to be 
incorporated into the catalog. A database application (to fit a user's business) is generated and updated in a 
number of phases, such as design, development, test and production, and in each one of these phases a 
facility exists for making alterations in the database definition (catalog), all of which make use of SQL to 
implement the changes. According to a feature of the invention, a change definition language (CDL) is 
provided which is an extension of (and in the general format of) the structured query language. The change 
definition language allows all important alterations to be described, as changes to an existing definition for 
example, and may be used by all phases of the development cycle. The CDL statements do not make' the 
changes directly in the catalog, but instead work through SQL and another intermediate mechanism such as 
DB2 ALTER tailored to make changes using SQL. The changes expressed in CDL may be migrated to 
downstream phases and fed back to earlier phases by use of a batch of change statements expressed in 
ODL. 

The novel features believed characteristic of the invention are set forth in the appended claims. The 
invention itself, however, as well as other features and advantages thereof, will be best understood by 
reference to the detailed description of specific embodiments which follows, when read.in conjunction with 
the accompanying drawings, wherein: 

Figure 1 is a diagram of tables, indexes and views in a simplified example of a database; 

Figure 2 is a map of memory containing a database system such as would include the application 

example of Figure 1 ; 

Figure 3 is a diagram of tables in the catalog of a DB2 database for a database application; 

Figure 4 is a diagram of a computer system which may be used for implementing a database 

management system such as that of Figures 1 and 2; 

Figure 5 is a diagram of a design, development, test and production cycle of a database application; 
Figure 6 is a map of data structures stored by a computer system having a DB2 database application 
therein; 

Figure 7 is a diagram like Figure 5 of phases in a database application, showing migrating forward and 
feed back^of batches of change statements made in a change definition language according to one 
embodiment of the invention; 

Figure 8 is a diagram representing the steps in a method of generating changes in a database catalog 
using the change definition language of the invention; 

Figure 9 is a diagram representing the steps in a method of generating changes in a database catalog 
using the methods of the prior art; 

Figures 10 and 11 are a diagram of a method of implementing changes in a database system using the 
CDL of the invention; and 

Figure 12 is a logic flow chart of a simplified method implemented in the change manager of Figure 11. 
RELATIONAL DATABASE SYSTEM 

A relational database product is a software database that appears to the user as if it were a number of 
tables, such as the tables 10, 11 and 12 of Figure 1. with each table including a field that is also used in 
another table (i.e., "related" to another table). A table 10 has rows 13 and columns 14, where each row is a 
"record" and each column is a "field" of this record, so all records in a table have the same fields or 
columns. There can be an arbitrary number of records (rows) in a table within the constraints of available 
storage space, and usually the rows are in the order that the data is entered rather than in some ordered 
sequence. In this simplified example database of Figure 1 the purpose is to keep track of employees and 
work projects for a small company, and the table 10 has the name "Employees" and contains columns for 
first name, last name, employee number, address, etc. The table 11 is called "Projects" and has columns 
14 for Project Number, Manager (identified by employee number), Department, and Location. The table 12 
is called Work_Week and for each employee records what project number he worked on in the week 
ending on the date indicated in the Week column. In a relational database a table may have a key field 15 
(sometimes specified as it must be unique to a reqord, i.e., no two records in table 10 can have the same 
value for this key field 15). In this example, the employee number column is the key field 15 in table 10, 
and project number can be a key field in table 11. An employee number will appear more than once in the 
table 12, indeed once every week, so the Employee__No column cannot be a key column if specified as a 
unique key column. In table 11, the Project_No column is a key field, and in this table each project number 
should be used only once. 
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In order to speed up the task of finding a given record, it is possible to create indexes of the data in the 
tables, so if the tables are spread over a large number of pages in the storage system, the value being 
sought can be found without searching through the entire mass of data without direction. For example, an 
index 16 as seen in Figure 1 contains only the employee number (from table 10) and a pointer 17 to the 
. 5 actual physical page number where this record is stored. Thus, to retrieve a record for a specified 
employee, it is merely necessary to retrieve the index 16, then retrieve the page pointed to by the pointer 
17, rather than blindly retrieving all that pages containing the data of the table 10 and searching for the 
specified employee. Tables such as the table 16 can be created for other columns, such as last names, 
SSNs, etc., as may be useful. 

w Another characteristic of this type of relational database product is a "view." A view is an alternative 

way of looking at the data in one or more tables. An example of a view 18 called Address List is shown in 

Figure 1, where the last name, first name and address columns from table 10 are extracted and appear as 
columns of the view. Thus, a view has rows and columns just as a table, but a table is physically stored as 
such, while a view is not. A view is generated from the data of the stored table when its use is invoked. A 

75 view may be used to control access to a table; access to a view can be granted without granting access to 
the table itself, so the view shows only portions of the data in the table, screening out sensitive data, e.g., 
the pay column, etc. Or a view can be used to combine data from two or more tables. 

Of course, the example of Figure 1 is grossly simplified; a typical implementation of a database such as 
DB2 on a large mainframe may have many thousands of tables, indexes and views, and the number of 

20 records (rows) in some tables may be in the hundreds of thousands or millions. Generally, the database 
products of interest here include those capable of maintaining the largest of database applications, such as 
nationally-based credit card accounting and verification systems, or the like. 

Referring to Figure 2, a database system is thus stored in storage 19 as a block of data 20 which 
includes the actual values in the rows 13 of all the tables, plus the values in all of entries in the indexes 16. 

25 This data 20 is stored in physical storage in pages, partitioned in ways that are important from a 
performance standpoint, in addition, a catalog 21 is stored which is the definition of all of the tables (name 
of table, name of columns, specification of data types in columns), a definition of all of the indexes (name, 
columns, pointers), a definition of all of the views, and the other objects of the system, all this itself being in 
the form of a set of tables. That is, in the catalog 21 there is standardized set of tables, including a table of 

30 tables, a table of columns, a table of indexes, and a table of views, etc., as discussed below. Thus, to create 
or to change a database definition, the standard tables of the catalog are filled in and updated. Also stored 
in memory as illustrated in Figure 2 is the database program 22 itself (e.g., IBM DB2), which defines how 
the catalog 21 is set up and how the data 20 is accessed using the catalog. As part of the database 
program 22, or as a separate module, there is a mechanism for controlling user access to the database and 

35 catalog for both defining the database and then for accessing it, referred to herein as a structured query 
language or SQL, in a block 23 of Figure 2. As will be later described, an additional module 24 may be 
included, according to the invention, to provide a change mechanism (using as input a set of statements in 
a change definition language) to be used along with the SQL module 23 to make changes in the catalog 21 
and thus alter the database definition. 

40 Referring to Figure 3, when operating with the IBM DB2 product as referred to herein, a SYSTABLES 
table 25 in the catalog 21 contains one row for each table, view or alias, and the columns in this table 25 
include the name (NAME) of the table, view or alias, the authorization ID (CREATOR) of the owner of the 
table, view or alias, the type of object (TYPE) as a table, view or alias, the database name (DBNAME), the 
tablespace name (TSNAME), the number of columns in a table or view (COLCOUNT), the number of 

45 relationships (e.g., tables) in which the table is dependent (PARENTS), the number of relationships in which 
the table is a parent (CHILDREN), and various other columns as set forth in the detailed specification of the 
product. A SYSCOLUMNS table 26 in the catalog 21 is another of the principal tables, set up by the 
database program 22 to record the columns used in any of the tables or views; this records (in columns) the 
name of the column (NAME), the name of the table or view containing the column (TBNAME), the 

so authorization ID (TBCREATOR) of the owner of the table or view that contains the column, the column 
number or numerical place (COLNO) in the table or view, the datatype of the column (LENGTH), and 
various other columns as set forth in the detailed specification. Another table 27 referred to as the 
SYSDATABASE TABLE in DB2 contains one row for each database set up by the 'present instance of the 
DBMS, and records the name and- creator in columns, as well as the storage group and bufferpool which 

55 are related to physical storage and retrieval, as will be- described. Another pair of important tables are the- 
SYSDBAUTH table 28 and the SYSTABAUTH table 29, which record the grantor and grantee for any 
privileges granted, the database or table name for which granted, the time and date, and details of what 
privilege was granted. A SYSINDEXES table 30 and a SYSVIEWS table 31 record the indexes and views 
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record the values apparent from Figure 3 for indexes and views. Other tables are included in the catalog as 
explained in the DB2 product specifications. The change mechanism 24 of Figure 2 is for the purpose of 
generating statements for changing the set of catalog tables such as that of Figure 3, using as an 
intermediary a data definition language of the SQL module 23. 
s A database product 22 is created and sold to customers as a generic product, a DBMS or database 
management system, useful for an unlimited number of different applications. The customer then builds a 
customized database to fit its particular business by creating the tables, indexes and views, defined in the 
catalog 21, using the SQL Referring to Figure 4, the customer may be running a computer system having a 
CPU 35 and a number of terminals 36, with memory 37 and disk storage 38, as an example. The database 
70 system used by the customer includes the purchased database product 22 (e.g., DB2) which is the generic 
software, along with an applications generator product 23, such as SQL or structured query language as will 
be described, used to produce a customized definition of how the database is to be utilized locally, i.e., 
define the tables of Figure 1 using the catalog tables of Figure 3. This customized definition is usually 
created by first writing a description in a high-level language (other than SQL) using a. CASE tool to 
;s generate a file of SQL statements, then using the database program 22 to interpret the SQL statements and 
thus generate the catalog 21 itself. The actual data to be recorded and manipulated is stored in the data file 
20, which is raw data in a format described in the catalog 21. 

The development cycle of a database application such as that of Figures 1-4 is illustrated in Figure 5. 
The database "schema" or layout as to be defined in the catalog 21 is generated by a designer in design 
20 phase 40; the designer is skilled in systems analysis and in the programming languages used, e.g. the 
applications generator or SQL 23 or other language(s) used, and would usually be somewhat removed from 
the actual production use of the product in its final form in the field. For example, the designer need not be 
concerned with performance tuning factors, which are dependent upon the hardware configuration; indeed, 
this tuning may differ in various locations where the ultimate database application is used. The design 
25 created in the design phase 40 would be an instance of the database of Figure 2, shown in Figure 5 as a 
catalog 21a, and perhaps a stub or test version of the data 20a itself may be included, but this is not 
necessarily the real-world data to be eventually entered. A copy 22a of the database software 22 is 
available in the design phase, of course, and, if appropriate, a copy 23a of the applications-generator 
language, e.g., SQL, but often the designers use other tools for defining the application. According to the 
30 invention, as will be described below, the change mechanism 24 may be present in the representation of 
Figure 5, but the design-development sequence is described in general first. The database as defined by 
the designers (composed principally of the catalog 21a) is then transmitted to the development phase 41, 
where there are applications developers who are skilled programmers familiar with the applications 
programming language 23 (or other tool for defining the database) and in the customer's requirements in 
using the system. These people expand the definition in catalog 21a and recompile it to obtain the more 
complete definition in catalog 21b. As before, the data 20b is not yet necessarily the customer's real data 
as will ultimately be used, but is of the same format. The application then goes to the test phase 42, where 
all aspects are tested by a number of skilled users; this is a debugging phase, sometimes referred to a beta 
test. After the testing phase, when the application is deemed to be ready for release, it appears as another 
40 instance 21c of the catalog, and this goes to a production phase 43. There may be a number of different 
instances of the production phase 43, at different physical locations. Here, the data 20 of the database as 
described above is generated in complete and real-world form, and continuously updated on a day-to-day 
basis. In production, the database is used on-line by the ultimate users, which include the naive users who 
merely enter data, as well as skilled programmers who are maintaining the application, making corrections 
45 related to day-to-day problems surfacing from use on the line, and performance-tuning to achieve optimum 
speed and ease-of-use. After a period of use. the database is thus defined by another instance 21 d of the 
catalog, reflecting changes made due to problems encountered or new knowledge gained in production use. 

Thus, at each of these stages, the design phase 40, the applications phase 41, the test phase 42 and 
the production phase 43, a complete set of the components of the application exist. That is, the generic 
so database software 22, the applications development language 23, the dictionary or catalog 21 and the 
database data file 20 (in some test form, at least) all exist, and the skilled workers at each stage may make 
changes in the definition of the database application as it is expressed in the catalog module 21. A separate 
version 21a, 21b, 21c and 21d of the definition dictionary or catalog 21 is maintained at each stage 40, 41, 
42 and 43, so that a stable version is available for use at each phase/ During the initial creation of the 
55 application, and during the life of the application, many changes may be made at each stage. The 
designers at stage 40 will continue to upgrade the application to add new features and capabilities, the 
developers at stage 41 will continue to implement the updated design received from the design phase and 
make changes as needed, the test stage 42 will make changes dictated by testing, and the production 
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phase 43 (or multiple instances of production phase) wili continue to make changes required by day-to-day 
problems and varying working conditions. The designers working on updates need to take into account 
problems found in testing or production. It is thus desired that the changes made at any stage be migrated 
to succeeding stages, as well as fed back to previous stages. That is, after the initial design has been 
s passed downstream, it is not a desirable solution to merely pass along to downstream stages a revised and 
updated version of the application catalog 21, e.g., a catalog 21b from development phase 41 to test phase 
42, because the test phase 42 will have implemented their own changes to produce an instance 21c, 
including changes that have not been fed back to the development phase, so these would be lost if instance 
21b were adopted. 

70 The problem of making changes in the database definition and updating all instances of the database is 
compounded by the fact that the original definition in the design phase 40 (and perhaps development phase 
41 as well) may be done using a high-level language other than the application definition language 23 (SQL 
for DB2). For example, a CASE (computer aided software engineering) tool may be used by the designers 
in phase 40 to generate the definition of the tables of Figure 1 for the catalog 21, and this CASE tool 

75 generates a set of SQL statements for passing along to downstream phases. Subsequent changes made 
downstream in the development cycle, e.g., in the production phase, will be made in SQL. i.e., the built-in 
applications-generator language 23. These changes are not likely to be readily combinable. The SQL 
changes from downstream are not capable of incorporation into the CASE language definition generated in 
the design phase. More importantly, the downstream instances of the catalog 21 are no longer the same, 

20 after a time period where local changes have been made, and even if a list of changes is passed 
downstream for hand entry, the then existing local catalog 21 may not be compatible with the changes 
requested by the list. 

According to the invention, a change definition language (used for an input CDL file for the change 
mechanism module 24 of Figure 5) is provided, and this language may be used by all phases of the 
25 development and production cycle. This language makes use of the data definition language of SQL, and is 
indeed in a format very similar to SQL statements. Unlike SQL, however, the change definition language 
provides a full capability of defining and making changes in all objects of the catalog 21. As will appear, 
SQL alone was not suitable for describing some of the most important operations. 

Some characteristics of SQL and DB2 will first be described, then the change definition language will be 
30. described in more detail. 

STRUCTURED QUERY LANGUAGE 

The structured query language that is a part of DB2 has two major components, these being the DDL or 
35 data definition language and the DML or data manipulation language. The DDL is used for creating the 
database description or catalog, and for making changes in the catalog after it exists; the DDL does no 
actually make changes in parts of the catalog, but instead "drops" or cancels an object and rebuilds it. 

. The tables are created in SQL by a CREATE TABLE statement, which is of the structure defined 
exactly in the referenced publications, but is generally of the form illustrated in the following example for 
40 creating the Employees table 10 of Figure 1: 



CREATE TABLE EMPLOYEES 



45 



50 



( FNAME 
LNAME 

EMPLOYEE_NO 

ADDRESS 

SUPERVISOR 

DEPT 

PAY 

SSN 



datatype 
datatype 
datatype 
datatype, 
datatype , 
datatype , 
datatype , 
datatype 



NOT NULL, 
NOT NULL, 
NOT NULL, 



NOT NULL ) 



where the "datatype" is a specification of the type of data that must be entered "here, e.g., a string of 
alphanumeric characters of specified length, a floating point numerical value of specified length, a date. etc. 
55. The NOT NULL statement means a value must be entered for this column. 

A view in SQL, as discussed above in reference to Figure 1, is a single table that is derived from other 
. tables or from other views. A view usually does not exist in physical form in the,data 20, but is a virtual 
table instead of one that is actually stored, in the database. This limits the possible update operations that 
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can be applied to a view. A view is a way of specifying a table that is to be referenced frequently, even 
though it may not physically exist. For example, from the tables of Figure 1, it may be desired to retrieve 
the names of employees working on a project, so a statement is employed: 

CREATE VIEW PROJECT- WEEK 

AS SELECT FNAME, LNAME, PROJ_NAME 
FROM EMPLOYEES , PROJECTS 

When a view is not needed any more, a DROP VIEW command is used to dispose of it: 

DROP VIEW PROJECT_WEEK 

Views can be updated by an UPDATE command, which actually updates the values in the data 20 in the 
underlying tables from which the view is created. 

An important part of a relational database is the index. An index is an access structure or path that is 
specified on one or more columns of a table, making accessing rows more efficient. Executing a query will 
take less time if some attributes involved in the query conditions were indexed; the effect is noticeable if the 
number of rows is quite large. The command to generate an index of the last name column for employees 
from the Employees table of Figure 1 is: 

CREATE INDEX LAS T_N AMES 
ON EMPLOYEES (LNAME) 

The actual index would have for each employee last name a pointer to the row in the Employees table for 
this instance. Transparent to the user, the pointer specifies the page in the virtual memory system where 
this row is physically located, so it is not necessary to retrieve all pages from disk to search for a particular 
employee. There is a time saving in execution, of course, only if there are a large number of pages needed 
to contain the Employees table, i.e., a large number of employees. If the table was contained on one or two 
pages of memory, then the recovery time would be increased instead of decreased by using a table, 
because it would be necessary to first recover the index itself, then retrieve the page based on the pointer 
found in the index. If the number of pages of employees is large, however, creating indexes on often-used 
reference attributes such a last name, employee number, or SSN provides a noticeable performance 
improvement. 

It is necessary to provide security and access privileges in some manner, and SQL does this with 
GRANT and REVOKE statements. Some users may be prohibited from accessing certain data, typically 
salary data, for example, in the Employees table of Figure 1. Some commands are allowed to be executed 
only by certain classes of users. A naive user, entering data or transactions at a terminal, may have access 
to no SQL commands at all, but instead uses the database only by means of applications programs written 
by the designers. A database manager may need to have access to all data and certain SQL commands, 
but not all, whereas a systems administrator may need a different set of access rights. A system designer 
of course needs access to all commands. To this end, a DBMS has an authorization subsystem which 
enforces these restrictions. User accounts are created, and a person needing access to a database must 
have an account, with account number and password, and a user must login using valid account number 
and password, administered by the authorization subsystem, under control of a privileged user such as the 
systems administrator. The systems administrator can issue a command 



GRANT CREATETAB 

TO Acctl 
i 

which grants to the user having account number Acctl the right to create tables (CREATETAB). i.e., to 
execute the CREATE TABLE command. This also grants to user Acctl the ownership of the tables created, 
and the right to say who has rights to use the tables. Then this user issues commands to create the tables 
of Figure 1 , and also issues the command 
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GRANT INSERT, DELETE 
ON EMPLOYEES 
TO Acct2 

which gives the user Acct2 the right to insert and delete rows in the Employees table. Only if a clause 
WITH GRANT OPTION is added can the user Acct2 propagate the right to other users. 

A relational database system relies on key values to constrain the relationship between information in 
related tables. When a column is designated a key value, then its value must be unique; no two rows can 
have the same value for a key column. For example, in Figure 1. the employee number would be a key, so 
no two employees can have the same number. The create index command is used to designate a column 
as a key, as follows: 

CREATE UNIQUE INDEX EMPLOYEE_NO_INDEX 
ON EMPLOYEES (EMPLOYEE_NO) 

which generates an index called Employee_No_index that requires each employee number to be unique. 
The department numbers and SSNs can be likewise declared unique, so there can be no duplications. 

The SQL language is a special-purpose high-level programming language that frees the database user 
from working with the actual physical data structures used in the database. The commands generated by. 
the user of SQL may be employed interactively (in real time) at a terminal, or for "canned" inquires or 
transactions are compiled by the SQL module or a compiler to generate code for defining the data 
structures for storage and retrieval. SQL statements can be used in conjunction with a general-purpose 
high-level programming language such as C, Pascal, Cobol or PL/I, for example, or with assembly language, 
in which case the other programming language is the host language. An SQL statement, e.g., a data 
definition, query, update, view definition, or index creation, can be embedded in a host language program, 
using some specified designator to separate the SQL statements from the host language code. For 
example, in PL/I the keywords EXEC SQL precede an embedded SQL statement. In some cases SQL 
statements can be passed as parameters in procedure calls. The names given to columns and tables are 
then declared as variables in the host language, and the actual physical data of the database manipulated in 
this way. 

When a table, index or view is created using the SQL statements discussed above, the tables of Figure 
3 in the catalog 21 are changed to reflect the appropriate information. 

The other part of SQL, as mentioned above, is the DML or data manipulation language, used for 
entering data and accessing the data in the database data section 20. The DML is not used in connection 
with the CDL of the invention. A DBMS using SQL has one basic statement in DML for retrieving data from 
a database, and that is the SELECT statement. The exact format of this statement is given in the referenced 
publications for IBM DB2. However, in general, a SELECT statement specifies the table from which the data 
is to be recovered, the columns to be recovered, and the conditions, a Boolean expression that identifies 
the rows to be retrieved. For example, the statement: 

SELECT ADDRESS 
FROM EMPLOYEES 

WHERE FNAME = JOHN AND LNAME = SMITH 

selects the address column from the table 10 called Employees in Figure 1, for the row having first name 
John and last name Smith. In a similar manner, the statement: 

SELECT * 



FROM EMPLOYEES 

WHERE SUPERVISOR = 04 5 
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selects a list of all columns for the Employees table 10 having a supervisor whose employee number is * 
"045." SELECT statements can be nested, such as: 



SELECT LNAME, FNAME 

FROM EMPLOYEES 

WHERE ( SELECT PROJECT_NO 
FROM PROJECTS 
WHERE MAN AG ER_NO = 073 ) 

selects last name and first name columns from the Employee table for employees having a Project No. 
where the project manager (selected from the Projects table) has an Employee No. = 073. 

The DML part of SQL includes three commands for modifying (entering data into) a database, these 
being INSERT, DELETE and UPDATE. In simple form, INSERT is used to add a row to a table, and is of 
the general form: 



INSERT INTO EMPLOYEES 

VALUES ("James", "Brown", "092", "125 Maple St. 
Houston TX 77039", "053", "007" 
"12.75", "754-75-7566") 

which would insert values for all columns of a new row in the Employees table of Figure .1. If only some but 
not all of the values are known, the insert would be of the form: 



INSERT INTO EMPLOYEES (FNAME, LNAME, SSN) 
VALUES ("James", "Brown" , "754-75-7566") 



The delete statement is of a form very similar to the insert statement, but deletes a row or rows from 
table: 



DELETE FROM EMPLOYEES 
WHERE LNAME = "Brown" 

would delete all rows having a employee's last name "Brown." The update command is used to modify 
column values of one or more selected rows, where a SET clause specifies the column or columns to be 
modified and their new values: 

UPDATE EMPLOYEES 

SET ADDRESS = "3 21 Westview" 
WHERE EMPLOYEE NO = 09 3 



DATABASE 2 (IBM DB2) 

The database management system (DBMS) product for which the change definition language of one 
embodiment of the invention was specifically designed is DB2 or Database 2, a commercially available 
product of IBM Corporation, for use with the MVS operating system. Database 2 or DB2 is described in a 
number of publications of the IBM Corporation, particularly the so-called "IBM Database 2 Version 2 
Release 2 Library" which is a collection of ten books including titles such as "Application Programming and 
SQL Guide, SC26-4377-1 ." The DB2 database product is a relational database environment, and a specific 
implementation of the query language (discussed in general above) called SQL or Structured Query 
Language is used to access data in the DB2 database product using DML, and to create or alter a database 
definition using DDL The principle of SQL here, as in other implementations of SQL, is that a single 
statement directed to DB2 may be used to select, create, or otherwise operate on the data, rather than 
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requiring a user to code a sequence of instructions explaining how to access the data. SQL provides full 
definition and data manipulation capabilities which qan be used to define objects such as tables, indexes, 
views, etc., (there are eleven principal objects) as well as retrieving, inserting, updating, deleting data, and 
controlling access authorization to data. The eleven principal objects in DB2 are database, table, view, 

5 index, storage group, tablespace, synonym, alias, authorization, plan and foreign key. 

The actual physical storage in any large DBMS implementation is necessarily partitioned in some way 
due to the system configuration, memory size, page size, construction of secondary storage, etc. In DB2, 
the database is a collection of logically related objects, i.e., the physically-stored tables and indexes. The 
terminology used in DB2 to describe the partitioned areas of storage includes terms such as "storage 

w group," "tablespace," "indexspace," "bufferpool," etc. Tablespace refers to the part of secondary storage 
where tables are stored and indexspace refers to the part where indexes are stored. A page is the unit used 
in data transfer between primary storage or memory 37 and secondary storage or disk 38, and a "space" is 
a dynamically-extendable collection of pages. Referring to Figure 6, the secondary storage of the computer 
system of Figure 4 may contain, in one example, a user database called DBX (that is, the data 20 for a 

, 5 created database having the name DBX) and another called DBY. Within a database is defined one or more 
tablespaces, such as the tablespace XA and tablespace XB seen in the Figure. Within each tablespace are 
the data areas for stored tables (one or more), shown as tables XA1-XAn and XBl-XBn. A storage group is 
a collection of direct-access storage areas from the same device type (e.g., a disk 38); there is no one-to- 
one correspondence between a database such as DBX and a storage group, so in Figure 6 it is seen that 

20 the same storage group contains all of database DBX and part of DBY. Views do no occupy corresponding- 
storage, and can be defined over multiple tables from different databases, so no storage area in Figure 6 is, 
allocated to views. Bufferpool is a term referring to main memory 37 area reserved to satisfy the buffering 
requirements for one or more tables or indexes. 

In DB2, the GRANT and REVOKE statements in SQL determine specific operations granted to or 

25 revoked from a user, and are in several categories, such as table and view privileges applying to existing 
tables, database privileges applying to creating tables, storage privileges dealing with the use of storage 
objects such as tablespaces and storage groups, and system privileges applying to operations such as 
creating a new database. There are certain bundled privileges specific to DB2, referring to assortments of 
privileges. These include the system administrator or SYSADM privilege which is the highest-order privilege 

30 and includes all possible operations within the system. A database administrator DBADM privilege on a 
specific database allows the holder to execute any operation on that database. A database control 
DBACTRL privilege on a specific database is similar to DBADM except that only control operation and no 
data manipulation as in SQL are allowed. The database maintenance DBMAINT privilege is a subset of the 
DBACTRL privilege and allows the holder to execute read-only maintenance operation such as back-up on 

35 the database. The system operator privilege allows the holder to perform only console operator functions 
with no access to the database. The design and development phases discussed to above with reference to 
Figure 5 thus require SYSADM privilege level as it is necessary to make changes to all of the tables of 
Figure 3. 

40 ALTERING A DATABASE CATALOG USING STANDARD SQL 

There are statements in the DDL part of SQL that aifow certain alterations to be made in a database 
definition as it is specified in the catalog 21, after the tables, indexes, views and other objects of the 
database have been initially defined. These are statements such as ALTER TABLE, ALTER INDEX, and 
45 DROP (TABLE, VIEW, etc.). For example, a statement: 

ALTER TABLE EMPLOYEES 
ADD ZIPCODE datatype 

50 

would cause a column named ZIPCODE to be added as the last column of the Employees table of Figure 1, 
using a datatype as specified. This table will have the same owner and the same name as before. The 
detailed specifications for the ALTER TABLE statement and other statements for altering elements of a 
database using standard SQL/DDL are given in a pp. 100-121 of the publication "IBM Database 2 Version 2, 
55 SQL REFERENCE Release 2" available from IBM Corporation as item number SC26-4380, which is a part 
of the Library mentioned above. 

Similarly, an ALTER INDEX statement in the existing SQL specification is available to make limited 
changes for an existing index. For example, the statement: 
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ALTER INDEX EMPLOYEE NO 
CLOSE YES 

s specifies that the data sets for the index are closed when the number of processes using the index 
becomes zero. 

The syntax diagrams used in SQL statement definitions have been described in publications such as 
SQL REFERENCE and elsewhere in the literature (and in Appendix A). The syntax diagrams are read from 
left to right and top to bottom following the path of the lines. The beginning is a double arrowhead on the 

w left pointing to the right, and the end is a pair of arrowheads on the right pointing to one another. A single 
arrowhead on the right of a line indicates the statement is continued on the next line, and on the left 
indicates a statement is continued form the previous line. Required items appear on the horizontal line (the 
main path), and optional items appear below the main path. If two or more items may be chosen, they 
appear in a stack, and if one must be chosen then one item of the stack appears in the main path. An arrow 

75 returning to the left, above the main line, indicates an item that can be repeated separated by a space, 
while if the repeat arrow contains a comma the repeat items are separated by a comma. A repeat arrow 
above a stack indicates that more than one choice can be made from the stacked items, or a single choice 
repeated. Statements and keywords appear in uppercase and variables (user-supplied) appear in lowercase; 
a default parameter appears in boldface underscored. Sometimes a single variable represents a set of 

20 several parameters, in which case the variable parameter block (in lower-case boldface) is shown as a 
diagram following the end of the main path; the variable parameter block may be replaced by any of the 
interpretations of such a diagram. 

The changes that may be made in a database definition using standard SQL/DDL statements such as 
ALTER TABLE are seen to be very limited. For example, there is no facility for changing the owner in any 

25 of the ALTER statements; the only way to change the owner is to create a new table or other object by the 
user who is to be the owner. And, there is no capability for anyone other than the creator/owner of a table to 
make changes in a table. Likewise, there is no facility for changing the name of a database, a table, an 
index or a view. A very important shortcoming is the inability to change columns in a table except to add a 
column; there is no facility for changing a column name or datatype, or moving a column to a particular 

30 place in a table, or changing the NULL7NOT NULL specification, for example. To make these types of 
changes, it has been the practice to drop a table and create a new table with the desired specification, and 
along with this it is necessary to generate a lengthy sequence of steps in a language other than DDL 
because the existing data for the previously-defined table must be preserved and transferred to the new 
table. 

35 For example, to change the length of a column, the actual steps generated by the BMC ALTER 

program mentioned above, using DDL (without the CDL concepts of the invention) would include: 



UNLOAD data from data 20, change length in unloaded 

data 
DROP table 
CREATE TABLE 
LABEL ON table columns 
GRANT authorizations on table 
CREATE SYNONYMS 
CREATE INDEXes 
CREATE VIEWs that use table 
CREATE VIEWs that use views 
LABEL ON view columns 
GRANT authorizations to views 
LOAD data 

RUNSTATS on table spaces and indexes 
IMAGECOPY table space 1 

Precompile, compile, link applications programs 
BIND application plans 

Of these steps, the DROP, CREATE, LABEL ON, and GRANT statements are DDL statements, but the other 
steps are coded by other languages. 
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Thus, the BMC DB2 ALTER product mentioned above operates by using SQL/DDL in combination with 
non-DDL' code to change the data structure and the, definition of the data structure of a database. In the 
example above, a column width may be changed by using data accessing steps to save the data, a DDL 
DROP statement to cancel a table containing the column, then rebuilding the table with a different-sized 
column using CREATE, and then reloading the saved data into the new data structure. 

Due to these limitations in the change or alter operations permitted by standard SQL/DDL, it has been 
inefficient to use SQL alone as the language for making changes in all phases during the design, 
development, test and production phases of a database application. Particularly, the constraints on the 
standard SQL language have made changes to the catalog 21. particularly the tables of Figure 3, awkward 
and unreliable for the early phases of the cycle, especially when migration of the changes to downstream 
phases, and feedback to earlier phases, is needed. 

Similarly, the BMC ALTER product mentioned above, while it greatly expands the facility for making 
changes in an maintaining a database application, still requires all changes to be individually entered by a 
programmer at a terminal, interactively, and does not account for the situation where the local instance of 
75 the catalog has been changed so it is different from that in an earlier instance. 

CHANGE DEFINITION LANGUAGE 

According to one embodiment of the invention, interpreter apparatus for a change definition language 
(CDL) is provided in the form of a program instruction for a preexisting programmable processor, so that a : 
user can write statements to make changes in an existing database to accommodate a wide variety of , 
commonly-needed alterations in almost all objects of the catalog or definition of the database. This change 
definition language is defined by the specification of the permitted statements set forth in Appendix A. 

The details of one implementation of the change definition language of this embodiment are described 
in Appendix B, which is a BNF grammer definition with Action C routines, used as an input into a LEX/YACC 
parser tool commercially available from MKS (Mortice Kern Systems); parsing a group of CDL statements 
and transforming them into machine-executable form is a matter of routine for those of ordinary skill having 
the benefit of this disclosure. 

The change definition language of this embodiment is written in a style very similar to SQL, so that a 
programmer skilled in using SQL, particularly the DDL part of SQL, will be able to use CDL with a minimum 
of instruction. The full SQL facility 23 is needed, for CDL to operate, i.e.. SQL/DDL must be present for 
reference when interpreting, analyzing and executing a set of CDL-defined changes, or must be present if a 
change statement is entered interactively. The statements of the change definition language are indeed 
implemented using the underlying SQL/DDL statements and code. 

Referring to the statements of the embodiment of the change definition language of Appendix A, an 
ALTER TABLE statement is available which is greatly expanded in capability, compared to that of the 
standard SQL as set forth in the SQL REFERENCE publication. For example, to change the Address 
column in the Employees table of Figure 1 to allow a more lengthy address to be recorded, and to change 
the name of this column to Home_Address, a statement would be used as follows: 
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ALTER TABLE Accntl . EMPLOYEES 

ALTER COLUMN ADDRESS new_datatype 
ALTER COLUMN ADDRESS NAME HOME_ADDRESS 

To add a column named Zipcode to the Employees table, positioned after the Address column (instead of 
at the end), the following statement would be used: 

ALTER TABLE Accntl . EMPLOYEES 

ADD COLUMN ZIPCODE AFTER ADDRESS datatype 

To move the Emp1oyee_No column to the beginning, so it is the first column, the following statement is 
used: 

ALTER TABLE Accntl . EMPLOYEES r , 

ALTER COLUMN ADDRESS MOVE BEFORE LNAME 
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The owner of a table is changed from user "Accntl" to user "Accnt2" by an ALTER TABLE statement as 

follows: 

ALTER TABLE Accntl ♦ EMPLOYEES 
OWNER Accnt2 

The capabilities of the ALTER INDEX statement of Appendix A is also greatly expanded compared to 
that of standard SQL. The owner of an index is changed from user "Accntl " to user "Accnt2" by an ALTER 
INDEX statement as follows: 

ALTER INDEX Accntl . EMPLOYEE NO 
OWNER Accnt2 ~ 

An index can be changed from unique to not unique or vice versa; for example, an index of the SSNs from 
the SSN column of the Employees table of Figure 1 is made unique by a statement: 

ALTER INDEX Accntl. SSN INDEX 
UNIQUE YES 

The name of the Employee^ No index of Figure 1 is changed to Empl_Number by the statement: 

ALTER INDEX Accntl . EMPLOYEE NO 
NAME EMPL_NUMBER " 

The ALTER VIEW statement of Appendix A finds no counterpart in the standard SQL7DDL specification 
A user may change the owner or name of a view, add a column, change a column name (to agree with a 
changed table), drop a column from the view, etc. For example, to change the name of the view 
PROJECT_WEEK of Figure 1 to WEEK, and to add the employee number column from the Employees 
table and drop, the employee's first name column FNAME, the following statement is used: 

ALTER VIEW Acctl . PROJECT WEEK 
NAME WEEK " 
DROP COLUMN FNAME 
AS SELECT EMPLOYEE_NO 

FROM EMPLOYEES 

Another capability of the change definition language of Appendix A, as compared to the Alter 
statements in standard SQL/DDL, is that of defining the ownership of a database, a table, an index or a 
view, as being a user other than the current user. The CREATE DATABASE, CREATE TABLE and CREATE 
VIEW statements of Appendix A all have an alternative of changing the owner to one other than the issuer 
of the statement. 

By using the statements of the change definition language, in any of the phases of Figure 5, the catalog 
21 can be changed to describe the altered database by making changes to the tables of Figure 3. Referring 
to Figure 7, one way of implementing the migration and feedback is to create in one phase a batch file 45 
consisting of all of the changes (expressed in change definition language) made since the original design 
catalog 21a was passed to the development phase. This batch file of CDL statements is executed on the 
catalog 21b, which itself has been changed by the development people, so it is not the same as catalog 
21a. Thus, there may be inconsistencies. A characteristic of a program for executing the changes defined 
by the CDL of the invention is that when a change is attempted using an ALTER TABLE statement, for 
example, and an inconsistency is found (e.g., the column name has been locally changed), the ALTER 
statement will not execute but instead an error will be signalled and the changes can be reconciled by 
direct coding (e.g.. the columns names changed to be consistent). Similarly, a batch file 46 of all of the 
changes made by the production phase (since the catalog 21c was received from the test phase) may be 
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created and fed back to the design team, and this batch of statements executed on the latest catalog 
version 21a. Again, any inconsistencies will not execute and can be reconciled. 

Referring to Figure 8, it is noted that one typical way of using the CDL according to an embodiment of 
the invention is for the user to interact with a CASE tool 50 or other facility such as the BMC DB2 ALTER 

5 program which is commercially available, to generate a file 51 of statements in CDL. That is, the user does 
not write the series of CDL statements describing the changes he wishes to make in the existing database 
catalog, but instead the user inputs information into a computer-aided generator 50 which interprets the user 
input and writes the statements of the CDL file 51. The CASE tool or DB2 ALTER program 50 may be the 
same tool used by a designer in defining the data structure of a database, and is merely for the 

70 convenience of the user, since the CDL file 51 could also be created directly by the user. The CDL file 51 is 
processed by a parser 52 to import the CDL statements to change definition tables 53, in DB2 format (i.e., 
expanding the CDL statements into complete SQL-compatible sequences needed to effect the desired 
changes). The file 53 is processed by an analyzer 54 which generates a worklist 55 of changes which take 
into account dependencies and the like, and reconcile differences in names, etc., so that an executable 

75 worklist is provided. The old catalog 21b (for example) is then processed by the ALTER program 56 to 
generate the new catalog 21c. 

Referring to Figure 9, the same change operation as in Figure 8 is illustrated using prior art methods 
and facilities. It is seen that the processors 54 and 56 are prior art functions used in the previous methods 
as well as in conjunction with the CDL of the invention as represented in Figure 8. In the prior art method of 

20 Figure 9, however, the user interacted using the ALTER specification 57 (the user writing change orders) to. ; 
generate the change definition tables 53. The difference between the method of Figure 8 and that of Figure 
9 is that in the method according to this embodiment of the invention as seen in Figure 8 the user 
generates the change statements of file 51 (via the CASE tool 50 if desired) in a CDL language, which is 
subsequently translated into the change definition in SQL/DDL form. 

25 Referring to Figure 10, the operation of a change method using the CDL accordingito the invention, is 

illustrated. The database software 22 is maintaining a catalog 21 for a database have data store 20. Access 
to the database is via SQL 23 which includes DDL and DML. The change mechanism 24 includes the 
commercially-available BMC DB2 ALTER program 24a, which provides an interface for defining changes in 
the manner of Figure 9. That is, an interactive user interface 57 provided by ALTER program 24 allows a 

30 user to enter changes, for example, by merely typing over a column name or datatype in a structured 
display of the table on a screen for a given table in the database previously defined. The ALTER program 
24a generates first a description of the change expressed in DDL, and this is a series of statements as 
discussed above (UNLOAD, DROP, etc.), referred to as the list 53 of Figures 8 and 9. 

In addition to the facilities provided by the ALTER program 24a, the change mechanism 24 includes a 

35 change manager 24b which has the ability to accept a change definition (list 51 of Figure 8) expressed in 
CDL. This is in addition to the other facilities of ALTER program 24a, rather than in place of. The change 
manager 24b parses the CDL list 51 and thus generates the change list 53 of Figures 8 or 9. Note that the 
changes described in CDL in the list 51 are of the same types as could be generated by hand using the 
interface 57 for the ALTER program 24a. The difference is, the CDL list 51 is machine readable, as well as 

40 being of generally SQL format and readable by a programmer familiar with SQL with little additional training. 
The source of the CDL list 51 could be a user who hand-codes the list, but more likely it is generated 
by machine. For example, in a preferred embodiment, the CDL list 51 is generated by the facilities seen in 
Figure 11, where another copy of the database software 22 is maintaining another instance of the catalog 
21, referred to here as 21a. This instance of Figure 11 could be the design phase 40 referred to above, for 

45 . example. The access and definition mechanism or SQL 23 is present, and another instance of the change 
mechanism 24, including BMC ALTER and change manager. Changes could be made in the catalog 21a by 
a user engaging ALTER in an interactive mode as discussed above, or by entering change statements in 
CDL, or by use of a CASE tool 59 such as Bachman. After a series of changes have been made in . the 
catalog 21a, the CDL list 51 is generated by the change manager 24b. 

so An important feature of the method as depicted in Figures 10 and 11 is communicating the changes in 
a very precise set of statements as permitted by CDL, rather than the drop and rebuild type of definitions 
permitted by DDL. That is, DDL describes a change in terms of how the resultant structure is supposed to 
be rebuilt, rather than how an existing structure is to be changed. If a column is to toe changed in a table, 
DDL statements to accomplish this will, include a CREATE TABLE statement naming every column in the 

55 . table, whereas a CDL statement names only the changed column. Further, the CDL list 51 is a list of 
changes to a specified instance of the catalog 21. So, before generating the changes by the mechanism of 
Figure 11, the first step is to make a copy of the existing instance of the catalog (before this set of changes 
is made), and to this end a copy V1 of catalog 21 is made, then after the series of changes are 

15 



EP 0 534 466 A2 



implemented locally, another instance V2 is available. When the list 51 is generated to be sent to a 
downstream change manager, the way this is done is to compare version V1 with version V2 and generate 
change statements to define the differences; this could be done by maintaining a journal of the changes 
made and replaying it, but since there can be changes to changed parts, and items may be changed and 

5 then reinstated to their original form, it is more precise to generate the list 51 by comparing V1 and V2. 

Referring to Figure 12, this operation of generating the change list 51 as performed by the change 
manager module 24b of Figure 11 is illustrated in flow chart form. A loop depicted by block 60 indicates 
waiting for a change session to begin. When entering a change session, the first step indicated by block 61 
is to copy the existing catalog 21 to storage, so a reference is available when later the CDL list 51 is to be 

10 generated. The copy is referred to as version-1 or V1. Next a loop 62 is entered where the system waits for 
the user to enter a change, e.g., interactively at a terminal using BMC ALTER or using the CASE tool 59, 
and when a change is entered it is checked for compatibility at block 63, i.e., there is a check to see if a 
table exists by that name, a column by that name, etc. If not compatible, an error is displayed at block 64 
and the user is given the alternative of reconciling the difference, at block 65. If not, control returns to loop 

75 62, or, if so, the reconciliation is entered at 66. The compatible change is then checked at 67 for 
dependencies (a column being changed used in other tables, indexes or views, etc.), and these are 
reconciled at block 68. After, consistencies and dependencies are all checked and defined, the requested 
change is implemented at block 69, i.e., the catalog V2 is altered to implement the requested change and 
its associated necessary changes. The session can continue if needed, at decision point 70,. so additional 

20 changes are entered as long as the user wishes. When continue point 70 indicates "no," the output list 51 
is generated as seen in Figure x by first loading V1 and V2, blocks 72 and 73, and comparing the two, 
block 74. If they are different, ar list of the differences is generated at block 75, and this list is converted to 
CDL language at block 76, as by a parser, and sent out as the CDL list 51 . 

While this invention has been described with reference to specific embodiments, this description is not 

25 meant to be construed in a limiting sense. Various modifications of the disclosed embodiments, as well as 
other embodiments of the invention, will be apparent to persons skilled in the art upon reference to this 
description. It is therefore contemplated that the appended claims will cover any such modifications or 
embodiments as fall within the true scope of the invention. 
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APPENDIX A 



About This Manual 



This manual defines the syntax and functionality of CHANGE 
DEFINITION LANGUAGE (CDL), an extension of SQL's Data 
Definition Language (DDL). Where DDL provides onJy limited 
support for database modifications, CDL provides access to almost all 
of DB2's features 

This manual assumes a thorough understanding of DB2 data structures 
and the Data Definition Language (DDL) of SQL. It is intended for 
advanced users who will be reviewing CDL. or for software 
developers who will be writing programs that can either read or write 
CDL. Since CDL is an extension of DDL, this manual assumes a 
familiarity with the terms and concepts presented in the IBM SQL 
Language Reference. 

Since CDL is intended for import into BMC CHANGE 
MANAGEMENT for DB2, this manual includes an appendix on the 
format of CHANGE MANAGEMENT'S CDL input files. 

Conventions Several special elements were used in this manual to make it easier to 
use. They are as follows: 

NoU: 

A note contains important information. 



® Warning! 

Warnings alert you to situations that could cause 
problems for you, like loss of data, if you do not follow 
the instructions carefully. 



About This Manual 
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Syntax Diagram Elements 



The syntax diagrams in this manual present language statements from 
left to right, top to bottom, along a primary path line similar to the 
following: 
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The w> symbol indicates the start of a diagram, while the »h svmbol 
terminates a diagram. Required items (such as statement and 
P-rametev in the diagram above) appear on the main track; opuonaJ 
items appear below the main track, as shown by opt ion in the 
diagram below: 








frfr— statement - 


: *~* 


20 
25 








> . ! 

—option — 


► 


► 


Arrows are used to continue statements from one line to the next; the 
solid arrowhead symbol ► at the end of a line indicates that the 
statement is continued onto the next line, while a ► symbol at the 
beginning of a line indicates that the line is a continuation of the one 
above: 








>#— statement - 


•opt ion — — — p. 








►—additional 


options- — »« 


30 




• 


Multiple lines indicate that one path must be selected from two or 
more possible paths. If at least one selection is required, men one of 
the options will appear on the main track: 


35 






statement - 


opt ion_l —r- p-4 

— opt ion__2 






If all paths are optional, then they will all appear below the main track- 


40 






statement- 


" : X 

— option_l-| 
L- opt ion_2 — 1 



45 
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10 . 



75 



20 



25 



30 



35 



40 



Vertical Arrows above the main track indicate that one or more 
syntactical elements may be repeated. In the following example. :ce^ 
may he repeated one or more umes. separated hy spaces: 



-STATEMENT - 



If the items must be separated by commas, the repeat arrow will 
contain a comma: 



-STATEMENT ■ 



Multiple Selections are indicated by a combination of a repeat 
arrow and multiple selection tracks. For example, the following 
diagram shows that one or more paths may be selected from the list of 
available paths: 



-STATEMENT -*-opt ion_l ■ 



—opt ion_2 —J 



Usually, each possible path can be selected once and only once. 
However, in some cases, an path may be repeated (usually with 
varying parameters). Statements that allow paths to be repeated more 
than once will be noted in the description of the specific statement 
where applicable, and the repeatable items will be flagged with a 
dagger (t) character. 

In the example below, optional and option_2 may be specified 
only once, but opt ion„3 can be repeated multiple times. 



! 1 

— STATEMENT -*-opt ion_l — j~ 

! i 
—opt ion_ t — » 

— toption_3— ' 

\ Repeatable item 
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-KEYWORD- 



"variable* 



-blocJt- 



block : 



A Default Value appears in under] i nM type. The example below 
shows a statement where yes is the default option; if no item is 
selected, the statement will perform exactly as if yes were typed in bv 
the user: 



STATEMENT- 



-NO 



Keywords appear in all uppercase letters, and must be entered 
exactly as shown (contractions or abbreviations are not allowed) If 
keywords are entered in lowercase, they will be folded to uppercase. 

Variables are shown in ail lowercase letters, and indicate a point in 
the syntax where a substitution must be made by the user In the 
following example, the variable eolumn.name must be replaced with 
a 1- to 18-character-long identifier constructed according to DB2's 
rules for column names. 



►•—COLUMN — co lumn_name - 



If a variable name occurs more than once, subscripted numbers are 
used to distinguish one occurrence from another when references 
would otherwise be ambiguous: 



►•—MOVE -column : —r- BEFORE -t— column 2 



L AFTER 



Sub-Diagrams are indicated by variable names in bold type. When 
a portion of a syntax diagram cannot fit onto a single page, or within 
the boundary of a column, a variable name is used to represent a sub- 
diagram that is defined separately from the main diagram. For 
example, this diagram has a sub-diagram called coium,»p«c: 



• — COLUMN — ( — column_«p#c— ) 
colunn_sp«c : 

►-co 1 umn_pa r ame t e r s . . . 



Notice that, when the actual sub-diagram is defined, its name is 
followed by a colon, and does not appear on a syntax diagram line. 
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Variables Used in 



EP 0 534 466 A2 

Syntax Diagrams 



^) Noto: 

The following term definitions use the terms short and 
long identifier as defined in IBM'S SQL Reference. 
except that CDL does not currently support delimited 
identifiers. A short identifier is 8 "characters; a long 
identifier is 1 8 characters. 



a 1 ias__name 
a 1 ias_owner 
auth_id 

catalog_name 

column_name 

constant 

const ra int_name 

database_name 
index_name 
index.owner 
locat ion_id 

number 
part_number 



A long identifier which names an abas. 

A short identifier which names the owner of an alias, 

A short identifier recognized by the operating system as a valid 
authorization ID. 

A short identifier that names a catalog. 

A long identifier that names a column in a table or view. 

A value to be passed to a procedure; the type and syntax of a constant 
is dependent on the procedure, but will usually be a numeric or string 
value. 

A short identifier that names a referential integrity constraint (foreign 
key definition). 

A short identifier that names a database. 

A long identifier that names an index. 

A short identifier that names the owner of an index. 

A one- to 16-character-long identifier that designates a DB2 
subsystem. 

A DB2 integer datum. 

A number that identifies a partition in a partitioned index space or 
table space. When 0. identifies a non-partitioned index space or table 
space. 
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pjsswcrd 

3 L oq r rup_r l ame 
nubsy 3 Cem_ id 
synonym_name 
synonym^owne r 
Cab le_name 
table_owner 



A short identifier recognized by the operating system as a valid 
password. 

A short identifier that names a storage group. 

A one- to four-character identifier that names a DB2 subsystem. 

A long identifier that names a synonym. 

A short identifier that names the owner of a synonym. 

A long identifier that names a table. 

A short identifier thai names the owner of a table. 



tab les P ace.name A short identifier that names a tablespace. 



view_name 

view_owner 

volser 



A long identifier that names a view. 

A short identifier that names the owner of a view. 

A one- to six-character-long identifier that names a volume. 
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CDL Statements 

5 

This section presents each CDL statement individually. Each 
command description contains four pans: a syntax diagram, a brief 
description of the function of the statement, a description of each 
10 parameter used with the command, and an optional section on notes 

and warnings. 
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ALTER ALIAS 



- A L 7 E r AL IAS -a 1 las.cwnsr • - .— a 1 la ?. nane-- 



•^--OWfJE?- — a 1 ias_owner 

— NAME -a 1 Las_r.ame : . 

— TABLE - 



— r 

— local Lon_id— .— L-vi 



cabie.owner - .-table_name 



ew_owner — .— v i ew_name- 



j 



COMMENT - 'String' 

—NO COMMENT 



LABEL -'string ' 

— NOLABEL 



Description The ALTER ALIAS statement specifies changes to an alias definition. 

Parameters alias.owner! . alias^nan^ 

The name of the alias to be modified. 

OWNER alias_owner 3 

The new owner of the alias. 

NAME alias_name 3 

The new name of the alias. 

TABLE (location_id .) x_owner . x_name 

The new table or view referenced by the alias. 
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ALTER INDEX 



alterj?art_p«nns : 



— VJAT -cJ-alcg„wme ■ 



— STO-3PCUf- -scegroup. name ■ 



— PR IQTY— number - 
-SECQTY -number - 



-FCTPREE -number- 



-fR EE PAGE — number ■ 



— L. IM I7KEY — i — constant — ) - 

add_part_parm« : 

> VCAT -cacalog_name 



— STOGROUP-szogroup_name - 



— PR IQTY -number - 
S ECQTY -number - 



-LIMITKEY-{-*-constant 



— PCTFREE -number — 
— FREEPACE -number -J 



Parameters index_ownern . index_name : 

The name of the index to be changed. 

OWNER index_owner 2 

The new owner of the index. 

NAME index_name 2 

The new name of the index. 

UNIQUE (YES / NO } 

Defines whether the index as unique or not 



CLUSTER {YES / NO) 

Defines the index as a clustering index. 
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ALTER INDEX 



ALTER INDEX 



-.LTEP r:iD£TX - index__3wner • — . - i ndex_name * - 



-O'aKEF. — i r.de x_owr.e r ■ 

-NAME — index_name 

-UNIQ'JE YES 

-NO 



-CLUSTER YES- 

. -(JO — 
-S'JBPACES 1 — 



-8 : 

-BLFFFERPOOL BPO - 



-BP1 - 

i ' 

-BP2 -i 



—CLOSE —YES - 



L 



NO- 



I 
f 
I 

U ERASE— YES 



t 



J 



i t-NO- 

i 

^— DSETPASS —password 
; f -N0DSETPASS- 



j- t ALTER PART-parc_number -alter_p*rt_p*rm* - 
— t ADD PART— par t_number — add_p*rt_p*rm« 

J— t DROP PART-number 



— KEYCOLUMNS- ( -*-column_name - 



Uasc-^ 
i i 

^-DESC-J 



t Repeacable item 



Subdiagrams on following page. 



Description Description of this statement. The description should be a brief 
summary of the purpose, function, and use of the statement. 
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ALTER DATABASE 



ALTER DATABASE 

►♦—ALTER DATABASE— da L abac e_n a me • 



NAME -da :abd3e_name ; 

— OWNER -au-h_ id 

-STOCF T : JP -s tog rcup.name 

-SUFFER POOL BPO 

-BP1 

— BP2 

-BP3 2K- 



Description The alter database statement specifies changes to a database 
definition. 

Parameters database.namei 

The name of the database to be modified. 

NAME database_name 2 

The new name of the database. 

OWNER auth_id 

The new owner of the database. 

STOCROUP stogroup_name 

The new default storage group of the database. 

BUFFER POOL BPn 

The new default bufferpool of the database. 
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ALTER FOREIGN KEY 



ALTER FOREIGN KEY 



AL.7EF* FOF.E : J.*J KEY - cab i e_:wner • - - cab I e_.nan 



. -:onscra i r.c__name . 



- r jo r . am e 



-F EFEPENCETB — tdble_cwner: - . — table_name- — 



— KEYCOLLTMNS - ( — *— co 1 umn_narr.e )- 

-ON DELETE CASCADE 



— RESTRICT - 
—SET NULL — 1 



Description 
Parameters 



The alter foreign KEY statement defines changes to be made to a 
foreign key. 

table^wneri . table_name. . constraint.narae. 
The name of the foreign key to be changed. 

NAME const ra in t_name 2 / NONAME 

The new name of the foreign key. If noname is specified, then 
the name of the foreign key will be generated by DB2. 

REFERENCETB table_owner 2 . table_name 2 
The new reference table of the foreign key. 

KEYCOLUMNS (column_name_l ist ) 

The replacement columns to define the foreign key. 

ON DELETE {CASCADE / RESTRICT / SET NULL} 

The new delete rule for the foreign key. 
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ALTER INDEX 



SU 5 FACES n 

The new number of subpages for the index. 

BLTFEr POOL B?n . 

The new bufferpool for the index. 

C-03E {YES • NO} 

The new index close parameter. 

ERASE (YES / NO> 

The new erase rule for the index. 

DSETPASS^ password I NODSETPASS 

The new data set password for the index, nodsetpass 
removes a data set password. 

ALTER PART part.number Alt«rj?art jannj 

For a partitioned index, alters pan number according to the 
parameters in the block alter_p*rt:_parM. To alter 
parameters for a non-partitioned index, the part_number 
value must be zero (0). For example, 

ALTER INDEX . . . 

ALTER PART 0 PCTFREE 20 

ADD PART part_number »dd_p»rt_parm* 

For a partitioned index, adds a new part number according to 
the parameters in the block •dd_part_p*xm«. 

DROP PART number 

For a partitioned index, drops part number. 

KEYCOLUMNS ( column_name_l ist ) 

The replacement column list that defines the key for this 
index. 

VCAT catalog_name 

The new volume catalog to be used for the index. 

STOGROUP stogroup_name 

The new default storage group for the index. 

PRIQTY number 

The new primary allocation quantity. 

SECQTY number 

The new secondary allocation quantity. 
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ALTER INDEX 



FCTFPEE number 

The new quantity for percent of free space to retain in the 
index. 

FREE PAGE number 

The new quanuty for Ihe number of free pages to retain in the 
index.' 

LtMITKEY (constant.! isC) 

The replacement key limit list for this part of a partitioned 
index. 
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ALTER STOGROUP 

i 



ALTER STOGROUP 



5 


i 

j W> — ALTCr ST3CPOUP- 


-scogrr'jp_nanie- ■ * 




i 

i 


name; — 


10 


j —owner -auth_:d- 






j - VO LUMES — ! vo 1 


s e r — -■ — 




: — VCAT -cata log_r.ame 




| VCAT PAS 3 -pass 


*/o rd — ; 


15 


{ —NOVCATPASS 

1 


— • 


20 


Description 
Parameters 


The ALTER stogroup statement defines changes to be made to a 
storage group definition. 

stog roup_name. 

The storage group to be changed. 


25 




NAME stogroup_name 2 

The new name of the storage group. 

OWNER auth_id 

The new owner of the storage group. 


30 




VOLUMES ( volser_list) 

The replacement list of volumes in the storage group. 

VCAT catalog_name 

The new catalog of the storage group. 



VCAT PASS password / NOVCATPASS 

vcat pass password defines a new password for the storage 
group, while no vc at pass defines the removal of a password. 



40 
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ALTER SYNONYM 



ALTER SYNONYM 



A L T E£ S : JO" Y M - s y no ny m.own e r • . - j, y 



ynonym_.name • 



.'nonyrr_owner ; - 



— NAME — svnonvm narr.e 



-TABLE -j— tab L e_:wner — .-tab L e_name -r— 
L-view^owner - .- view name ' 



Description The alter synonym statement defines changes to be made to a DB2 
synonym definition. 

Parameters auth_isi. synonym_name : 

The name of the synonym to be changed. 

OWNER synonym_owner 2 

The new owner of the synonym. 

NAME synonym_name 2 

The new name of the synonym. 

TABLE x_owner . x_name 

The new table or view referenced by the synonym. 



CHANGE DEFINITION LANGUAGE (COL) Reference Manual 



32 



EP 0 534 466 A2, 



ALTER TABLE 



ALTER TABLE 



TEF. TABLE — t .a bl e_~vr.e : • - .-- jc-le - r.a.ne; - 



J^-OV.TI EP - 1 a b 1 e _own e r • — " ~ ~ 

—NAME - Cible.r.ame: — — " 

—DATABASE -da tabase.nair.e — ' " 

— ^ASLESPACE-tablespace.name — r 

ED ITPR OC -procedure _name — ' 

-r jo eo r t proc ■ — — 

VAL TDPF.OC -procedure.name ■ 

— hoval : dp roc — — : 

-audit — hone " " ' 

—CHANGES — 
—ALL ; 

— t ALTER COLUMN -column.name — alt«r_col_«p*c — * 

— t ADD COLUMN -column_name : —BEFORE —column_name : -add_eol_»p«c-. 

'—AFTER — ' : 

i 

— (DROP COLUMN— column_name — ! 



|— PR IMARYKEY- (-*-co luron_name — )- 
| —NO PR IMARYKEY — 



; — COMMENT - ' s c r i ng • ■ 
i— NOCOMMENT 



: — LABEL -'string' ■ 

i I 

—NO LABEL 



'~ t COLCOMMENT -column_name - ' string ' 
— t NOCOLCOMMENT -column.name ■ 



— t COLLABEL — co 1 umn_name - * s t r i ng ' — ' 

— » NOCOLLABEL -column.name : ~~ "* 

tRepeacabie icem Subdiagrams on following page. 



Description The alter table statement defines the changes to be made to a 
table. 
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ALTER TABLE 
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alter_col_ap«c : 



*— i-^-datatyp* 



-FOR BIT DATA ■ 



—OFF — 

— FIELDPRCC -procedure^nane ■ 



— (-^-constant - 



-NOF I ELDPROC ■ 



"—NOF I ELDPROC PA RMS - 
— NOT NULL 



— NOT NULL WITH DEFAULT — 
— NULL — 

- -MOVE BEFORE — cclumn.name- 

-AFTER i 

—NAME — co lumn_name 



add_col_»p«c : 
( — datatype - 



-FOR BIT DATA- 



— F I ELDPROC — procedure_name - 



1 ' I 

L {-^-constant-!— )— • 



-NOT NULL - 



i-NOT NULL WITH DEFAULT -j 

'-NULL ■• J 



Subdiagrams continued on following page. 



Parameters 



table_owner l . table.name! 

The fully-qualified name of the table to be changed. 

OWNER table_owner 2 

The new owner of the table. 
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ALTER TABLE 



d«t«typ« : 

» -JH.-.F hut be r - i < 

— '.'AFC HAP number — ■ ■ : 

va.p- hap '■ 

-lUTZZZF. - 

-SMALL I NT 

— FLOAT - ! -number — i 

— DEC IMAL — i — n urn be r — 

— , —number — 

—GRAPHIC- (-number — ) ; 

—VARCRAPHIC - {-number -> ; 

-LONG VARCRAPHIC [ 

•—DATE — 1 

*— TIME — : : 

— T IMESTAMP ' 



NAME table_name 2 

The new name of the table. 

DATABASE da tabase_name 

The new database of the table. 

TABLES PACE tablespace_name 

The new tablespace of the table. 

EDITPROC procedure_name / NO ED IT P ROC* 

ED IT p ROC defines a new edit procedure; noeditproc 
removes an existing edit procedure. 

VALIDPROC procedure.name / NOVALIDPROC 

validproc defines a new validation procedure; 
novalidproc removes an existing validation procedure. 

AUDIT {NONE / CHANGES / ALL) 

The new audit procedure for the table. 

ALTER COLUMN column_name alt«r_eol_»p«c 

Modifies column_name according to the specifications in the 
alt«r_col_»p«e block. 
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ALTER TABLE 



ADC COLUMN colunn_nane : ( BEFORE ■' AFTEF. ' 
1 uinn_r.aiT»e : add_eol_«p«c 

Adds a new column :clumn_name : before or after the 
existing column.name; according to the specifications in the 
add_col_»p«c block. column_name ; must always be the 
current name-that is. the name of the column before any 
changes are applied by the current CDL statement-of an 
existing column in the table; if multiple columns are added or 
moved after the same column_name 2 , they will be added or 
moved in the order specified. For example, the table x . tab 
consists of three columns named cola, colb. and colc. 
Executing this CDL command: 

ALTER TABLE X - TAB 

ALTER COLUMN COLB { NAME COLX) 

ADD COLUMN COL1 AFTER COLB ( INTEGER ) 

ADD COLUMN C0L2 AFTER COLB ( INTEGER ) 

would result in x . TAB having five columns (in order): cola, 
colx, coli. COL2, and colc. Note that, even though COLB 
was renamed colx in the statement, colb must be used in the 
add column clause, because the existing name of the column 
must be used. 

However, this CDL statement: 
ALTER TABLE X .TAB 

ADD COLUMN COLI AFTER COLB ( INTEGER) 
ADD COLUMN COL2 AFTER COLI (INTEGER) 

would result in an error since coli does not appear in the 
existing table x , tab. 

DROP COLUMN column_name 

Removes the column col umn_name from the table. 

PRIMARYKEY { column_name_l is t ) / NOPRIMARYKEY 
primarykey creates a new primary key for the table 
consisting of the columns specified in the column name list. 
This primary key definition replaces an existing primary key 
or creates one if it does not exist no primarykey removes a 
primary key definition from a table where one exists. 

COMMENT 'string' / NOCOMMENT 

comment adds the comment in 'string ' to the table; 
nocomment removes an existing comment definition. 
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ALTER TABLE 



LABEL 'string' ■ N0LA5EL 

label adds the label in -string' to the table; no LA BEL 
removes an existing label definition. 

CDLCOMMErJT column_name ''string' 

Adds the comment in 'string' to column_name. 

NOCOLCOMMENT column.name 

Removes the comment (if any) from colum.n.name. 

COLLABEL column_name 'string' 

Adds the label in 'string' to cblumn_name. 

NOCOLLABEL coiumn_name 

Removes the label (if any) from column_name. 

datatype 

Defines the column to be of the specified DB2 data type. 

Q Not«: 

FLOAT (number) and DECIMAL ( number I , number ) ... 



FOR BIT DATA (OFF} 

Defines the column to be for bit data. 

FIELDPROC procedure_name { ( constant_l is t ) ) / 
NOFIELDPROC 

fieldproc defines a field procedure for the column; 
nofieldproc removes a field procedure definition. 

NOT NULL / NOT NULL WITH DEFAULT / NULL 

Defines the null handling attributes of the field. 

MOVE { BEFORE / AFTER ) column_name 

Moves the column before or after col umn_name (which must 
be the current name of an existing column). For example, if 
the table x .tab contains the columns coli. COL2. and COL3, 
then this CDL statement: 

ALTER TABLE X .TAB 

ALTER COLUMN COLI (NAME COLX) 

ALTER COLUMN C0L2 {MOVE BEFORE COLD 

would result in a column order of col2 -colx-col3. 
However, this CDL statement 
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ALTER TABLE 



ALTER TABLE X .TAB 

AGO COLUMN COLA 9ET rZ : :<L1 feci _ ;pe z . , . 
ALTER COLUMN CJ>L: iMOVE BEFORE COLA: 

would result in an error, since cola does not exist in the table 
before the invocation of the CDL statement. 

NAME col umn_name 

The new name of the column. 

Notes and Warnings The add column and alter column clauses are positional m 

appUcation. That is. if the CDL specifies these three clauses 

alter table . . . 
add column col1 . . . 
add columm c0l2 . . . 
add column col3 . . . 

The columns will be added in the order specified, and will appear in 
that order in the table. 

For a runner example, if table x . tab contains col 1 . C0L2 . and COL3 . 
this CDL statement: 

ALTER TABLE X . TAB 

ADD COLUMN COL 4 NEW AFTER C0L1 ( FLOAT ( 2 1 > > 
ALTER COLUMN COL3 (MOVE AFTER COLD 

would result in a table order of coli -C0L4NEW-C0L3 -col2. 
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ALTER TABLESPACE 



ALTER TABLESPACE 



^LTE?: TABLESPACE:— da ^ aba s e_r.ame • - . -cab I e::pace_rsame 



-*-DATABASE-dacabase_name; - 

— r J AME -.ables pa re„name ■ 

— OWMER -auth_ia — 



— BUFFER POOL BPO • 

-BP1- 
— E?2 - 



-LOCKS ICE - 



— BP32K- 
-ANY 



-PACE- 



— TABLE - 



—TABLESPACE — 

—CLOSE YES— 

—NO ' 



! I 



-DSETPASS -password- 



^-NODSETPASS- 



r-SEGSIZE —number 



NUMPARTS-number 



r 

'—ERASE YES- 



-NO — 1 

— t ALTER PART — part_number — (-alt«r_p*rt_p*rm»- )- 



L, 



ADD PART BEFORE — i— pa r t_number — (— «dd_part _pitmi - ) -* 

i ' 

L- AFTER ■ i 



— tDROP PART —pare .number - 
I Repeatable iCem 



Subdiagrams on following page. 



Description The alter tablespace statement specifies the changes necessary 
to make a remote tablespace identical to a local tablespace. 

Parameters DATABASE database_name 2 

The new database for this tablespace. 



NAME cablespace_name 2 

The new name for this tablespace. 
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ALTER TABLES PACE 



«lter_part_pann« : 



— V - AT -:^:al>5_name 

— STOCPOVr -3 -cgrcup_name — 

— PF. [ STY -nur.be r 

-$Z::TY- nuir.be r 

— PC7FF.SE -number 

— FF EE PAG E-nu mbe r 

add_p«rt_para* : 

► VCAT —cat a Log_name 



*— STOCROUP-stogroup_name - 1 

!-PRIQTY-number-i 

! i 

-S ECQTY— numbe r - 



i—PCTFREE -number — \ 
— r REEPAGE— number— ' 

OWNER auth_id 

The new owner of the tablespace. 

ALTER PART part_number ( altar_part_parma ) 

For a partitioned tablespace (numparts > 1), modifies pan 
part_number according to the parameters in the 
altar_part__parma block. 

For a non-partitioned table space, parc.number must be zero 

(0). 

ADD PART parc_number { add — part_jpanna ) 

For a partitioned tablespace, adds a new part part_number 
according to the parameters in the add _p*rt__p*rm* block. 

DROP PART part_number 

For a partitioned tablespace, removes the definition of part 
parc_number. 
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ALTER TABLESPACE 



t-Jh r =.:- r' JOL FPr. 

The new default bufferpool for the tablespace. 



The new lock size for the tablespace. 

•:lose {yes . no > 

The new close parameter of the tablespace. 

DSETrASS password / NCDSETPA3S 

DSETPASS password defines a new data set password for 
the tablespace. while nodsetpass removes a data set 
password definition. 

SEC SIZE number 

The new segment size of the table space, or 0 to specify a non- 
segmented tablespace. DB2 requires SECSIlEto be between 
4 and 64 and divisible by four if segmented. 

NUMPARTS number 

The new number of pans for the table space, num parts =0 
specifies a non-partitioned table space. 

ERASE {YES / NO> 

The new erase parameter of the tablespace. 

PRIOTY number 

The new primary allocation quantity (valid only with 

STOGROUP, not VCAT). 
SECQ7Y number 

The new secondary allocation quantity (valid only with 

STOGROUP, not VCAT). 

PCTFREE number 

The percent of free space to be left on each page of the 
tablespace upon create or reorganization. 

FREEPAGE number 

Defines that a free page will be added after every number 
pages upon tablespace creation or reorganization. 
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ALTER VIEW 

ALTER VIEW 



*- i" - •- *- » L"-v. - v : e w_ r w r. e r - . - v ; n j n e : 



— •* *' w; ; e F -vie v_ o wner- 
--•'•'AtfE — v iew_na,ne- — 
— - KECK OPTION YES 



— MO — 

— --OMMEf IT - 'string' — 

-nocohme::7 — 



LABEL — ' s tr ing ' 

-NOLABEL 



t- t COL COMMENT -co 1 umn_name - ■ s t r i ng ' 
— t N'OCOLCOMMENT -column.name 



— t COLLABEL -co 1 umn_name — * string • 

— t MOCOLL ABEL— co 1 umn_name ■ 



— t ADD COLUMN-column^name, —BEFORE column name,- 

1 I ! 

-AFTER — > ; 

r- r ALTER COLUMN-co lumn_name t -NAME-co lumn_name 2 \ 

— t DROP COLUMN — column^ name j 



—AS SELECT —sub__se lect — ' 
t Repeacable icem 



Description 
Parameters 



The alter view statement defines changes to be made to an existing 
view definition. 



view_owner, . view_name : 

The fuHy-quaiified name of the view to be modified. 

OWNER view_owner 2 

The new owner of the view. 

NAME view_name 2 

The new name of the view. 
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l . ALTER VIEW 

ZHZCr -:pr;oN 'yes no* 

The new check opuon for the view. 

COMMENT 'scring' / NOCOMMENT 

comment ■scnng' defines a new comment for the view, 
while nocoMMENT removes an existing comment. 

LABEL ■ string' / NO LA 8 EL 

label * s t r l ng • defines a new label for the view, while 
nolasel removes an existing label. 

CCLCOMMENT column.name 'string' 

Defines a comment 'string* on column.name. 

HOCOLCOMMENT column.name 

Removes art existing column comment from column.name. 

COLLABEL column.name * string* 

Defines a label 'string' on column_name. 

NOCOLLABEL column .name 

Removes an existing column label from column_name. 

ADD COLUMN co Lumn.name, ( BEFORE / AFTER } column_name- 
Adds a new column column_name l to the view before or 
after the existing column column_name 2 (which must be the 
current name of the column). 

ALTER COLUMN column^namej^ NAME coIumn_name 2 

Modifies the column column_name 1 giving it the new name 
column. name2- 

DROP COLUMN column_name 

Drops column_name from the view* definition. 

AS SELECT sub_select 

Defines a new SQL subselect statement as the definition for 
the view. If specified the new select statement must appear 
last in the alter view statement, after any other clauses. 

Q Note: 

CDL does not support the with check option clause 
of DDL. Use CHECK OPTION (YES/NO) instead. SEE 
Create View. 
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CREATE ALIAS 



CREATE ALIAS 



■OP. EAT E A L I A 5 - a I ia:_own»r - .—a 1 ias_name 

fABLE pr.able_ow.ner- .-cable.name-j- 

— I oci c i on_ id—.— L./ iew _ owne r _ _ v i ew_r.ame ' 



— COMMEt IT --string'- 

— LA BEL — ' string ' 



Description The create alias statement creates a new alias for a remote table. 

Parameters alias_owner . alias_naroe 

The name of the alias to be created. 

TABLE {location_id .) table_owner . table.name 

The qualified name of the table or view referenced by the 
alias. 



COMMENT 'scring' 

An optional comment for the alias. 

LABEL 'string' 

An optional label for the alias. 
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CREATE DATABASE 



CREATE DATABASE 



: FEATS D.- 



^ : 

— (. : a f J Lf* — a u L h_ i d • 



— STOCROU? -stcgroup^nape- 

-BUFFER POOL gpQ 

— BFl 

-bf: 

-BP32K- 



Description The create oatabase statement creates a new database. 

Parameters owner auth_id 

The owner of the database. 



STOCROUP stogroup_name 

Assigns this database to the new default storage group 
stogroup__name. If the stogroup keyword is not specified, 
the default sysdflt storage group will be used. 

BUFFER POOL BPrt 

The default buffer pool to be associated with the database. 
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CREATE FOREIGN KEY 



CREATE FOREIGN KEY 



**-CF EA7E FOREIGN KEY -Uhle_:wner - - . - table_natne ► j 

1 

— . -cons c ra : nt_name — j 



j F.EFERENCETB -cable_owner- — .-:able_natne; 



j ►—KEYCOLUMNS -(-^-column.name — »- 

i 



-ON DELETE CASCADE 

— RFSTP TCT — 
-SET NULL- 



Description The create FORErcN key statement defines a foreign key for a 
table's referential integrity checking. 

table.owner, . table_name : {. constrainc_name) 
The quaJified constraint-name of the foreign key. If 
conscraint.name is not specified, a name will be generated 
automatically by DB2. 

REFER ENCETB table_owner 2 . table_name 2 
The table referenced by the foreign key. 

KEYCOLUMNS < column_name_l ist ) 

The columns to be included in the foreign key definition. 

ON DELETE (CASCADE / RESTRICT / SET NULL) 

The delete behavior of the referential integrity constraint. 
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CREATE INDEX 



CREATE INDEX 



CFEATE IN'OEX -index_3wner - . - i ndex_name- 
TABLE -table.owner — .-t.able_r.ame 



KEYCOLUMNS — i-*-colunr._r<a^e - 



-ASS — 
— CESC — 



-UNIQUE YES 

—NO 

-CLUST EP. — Y ES — 

—NO — ' 
-SUBPAGES 1 



r 4 ~i 

i-8— j 

UJ 



i 
l 

J— BUFFER POOL— — BPO — 

i Lbpi-) 



1-BP2 J 



«— CLOSE —YES - 

: t 

! *-NO — 

Lerase—yes- 



-NO 



J 



-OSETPASS — password - 



»- t PART -number -indtx_ptrt_p»nnj - 

t Repeatable icem 



Subdiagram on Col lowing page. 



Description The CREATE INDEX statement defines a new index for a table. 

index_owner . index.name 

The owner and name of the new index. 
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CREATE INDEX 



index .part parma : 

► VCAT -cata log.name 



>T'.*0? v*jf - jcogrcup_name • 



— PP IQTY -number — 
— 3ECQTY -number — 



-L IM ITKEY— i -^constant - 



-PCTFPEE -number — 

i 

-FP EEPAGE — number — 



TABLE table_owner . tabie_name 

The table the index is being created on. 

KEY COLUMNS ( column__name_l isc ( ASC / DESO) * 

The names of the columns to be included in the index, along 
with a keyword specifying the son order (Ascending or 
DESCending). 



UNIQUE (YES / NO> 

Defines whether or not index values must be unique. 

CLUSTER { YES /NO} 

Defines this index as a clustering index, if yes is specified. 

SUBPACES (1/2/1/8/16) 

Defines the number of subpages for the index. 

BUFFER POOL BPn 

Defines the default buffer pool to be used by the index. 

CLOSE (YES / NO} 

Defines the close action of the index. 

ERASE (YES / NO} 

Defines the erase action of the index. 

DSETPASS password 

Defines a data set password for the index. . 
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CREATE INDEX 



FART number iad«x_part_parm* 

For a partitioned index, defines the parameters for part 
nurber according to the block index_part_pann*. 

'/CAT C3 1 a 1 ca_name 

The cataiog to be used for the index. 

STOCRO'JP s -cgroup_name 

The default storage group for the index. 

FPIOTY number 

The primary allocation quantity for the index. 

SECCTY number . 

The secondary allocation quantity for the index. 

LIMITKEY (constant.list) 

The limiting constants for this pan of the index. 

PCTFREE number 

The percentage of free space to leave in the index space upon 
create or reorganization. 

FREEPAGE number 

Defines a free page every number pages in the index. 
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CREATE S.TOGROUP 



CREATE STOGROUP 



:P Z.\T£ STOGROUP -3 *, eg ro-F__name - 
-AT — caulog^name 



— VCATF ASS -pas sword — 



VOLUMES - ! -3-volser ) 



— TaTJER — auch — id — 



Description The create stocroup statement defines a new storage group to 
DB2. 

PsrameterS s togroup_name 

The name of the storage group. 

VCAT catalog_name 

The catalog of the storage group. 

VOLUMES (volser.list) 

A list of volumes to be included in the storage group. 

OWNER auth_id 

The owner of the storage group. 

VCATPASS password 

Defines a password to be used for the volume catalog. 
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CREATE SYNONYM 



CREATE SYNONYM 



-C FX ATE SYNONYM — syr.cnyin^swner — . — 3/ nc nyrn_r.ame ■ 



TAPLE -t— tabl e_>*ner - . -tab le.name -i : • I 



T-uoi e_>ne r — . - _ a c i e__.n ame — r 
Lv iew_ownet — . — viewer. <irre ' 



Description The create SYr;cr:YM statement creates a synonym for an existing 
table. 

Psr3m6t6rS syncnym_owner . synonym_name 

The owner and name of the svnonvm to be created. 



TABLE x_owner . x.name 

The table or view referenced by the synonym. 
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CREATE TABLE 



CREATE TABLE 



- JF.EATE TABLE — tab I e_ owner - .-cab L e_name- 



-COLUMTJS — i-*-column_daf iniclon )- 



— DATABASE —database 



— TABLES PACE -cablespace_natne- 

— EDITPROC -procedure_name 

— VALIDPROC -procedure_name ■ 

-AUDIT MONE , 



—CHANCES - 
—ALL 



— PR IMARYKEY - (-^-column.name }- 

—COMMENT - * string ' 

LABEL - ' string ' : — 



r- tCOLCOMMENT — column.name —' string ' - 
t COLLABEL -co 1 umn_name — • s t r i ng ' — 
t RepeaCable item 



Subdiagrams on following page. 



Description The create table statement defines a new table to the DB2 system. 

Parameters cable.owner . table_najne 

The owner and name of the table to be created. 

COLUMNS (coluina_def inition_liet) 

The column definitions for the table according to the 
column_d«f inition block. 

DATABASE database.natne 

The database for the table. 

TABLESPACE tablespace.name 

The tablespace used by the table. 

EDITPROC procedure_najne 

An edit procedure for the table. 
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CREATE TABLE 



column — definition : 
~ z \ 'j,T,n.rjr.e — data type - 



— rOr SIT DATA 

— r" I ELDPF.GC — p r ocedu re_narre - 



— i-I-constan: — i — 



— ;:ot rnjLL 



— NOT NULL WITH DEFAULT - 



datatype : 

» CHAR - (-number ->- 



— VARCHAR -I -number -}- 

-long varchar 

-integer 



—SMALL INT - 



—FLOAT - {-number-) 
-DECIMAL- (-number - 



i—,— number —I 
—GRAPHIC— f— number — ) 



— VARCRAPH IC - (-number - >- 

—LONG VARCRAPH IC 

— DATE 

—TIME 



-T IMEST AMP- 



VALID PROC procedure.narae 

A validation procedure for the table. 

AUDIT ( NONE / CHANGES / A1X ) 

The audit activity for the table. 

PR IMARYKEY ( column_name_l i s t ) 

The primary key definition for the table. 
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CREATE.TABLE 



COMMENT '3:r:r.;' 

A comment tor the table. 

LABEL ' string* 

A label for the table. 

COLCOMMENT column.name 'string* 

A column comment on column.name. 

COLLA8EL column_name 'scring' 

A column label on column_name. 

datatype 

The DB2 data type for this column. 

FOR BIT DATA 

For character columns, defines that the column should be 
treated as binary data, not EBCDIC characters. 

FIELDPROC procedure.name { < constant.lisc ) ) 
Defines a field procedure for the defined column, 

NOT NULL / NOT MULL WITH DEFAULT / NUM. 

Defines the null activity for the column. 
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CREATE TABLESPACE 



10 



15 



20 



25 



30 



35 



CREATE TABLESPACE 



VTH ?ArLESPA-rE-da-.abase_r.j:ne- .-tabte:"c.Yce_name- 



— t !7M PA F. T3-nurr.be r - 1 

_pipj —number -tabl«»pace_part» — 

- ?AF7 * -tableapace_parts - 



-OWNER -auth_id- 



— BUFFER POOL BPO 

-BP1 

— BP2 

— BP32K- 

— LOCKS ICE ANY 



-PACE- 



— TABLE- 



—TABLESPACE — 
— CLOSE YES 



: —no — ' 

— DSETPASS — password- 

— SEGSIZE —number 

— ERASE — t— YES— 



—NO — ' 
r Repeacable icem 



— * 



Subdiagram on following page. 
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Description The create tablespace command defines a new tablespace to a 
DB2 system. 

Parameters database_name . tablespace_name 

The database and name of the tablespace to be created. 
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CREATE TA'BLE SPACE 



table»p«ce_part a : 

► '. TAT Iog_name 



— STOC? T'JF' -dcgrcup^name ■ 

— FF.IQTY -number— 
— SECQTY— numbe r — 



—fZTFREE -number — 
— FREEPACE-number — 



NUMPARTS number { PART number tablespace_part s } / 

PART 0 tabLespace_parts 

If num parts > 0, then a partitioned tablespace is being 
created, and each pan must be specified according to the pan 
number and the parameters in the t»j>ieep«ce_part» 
block. If part 0 is specified, then the tablespace is non- 
partitioned and the table apac«_p«re* block is used to 
define it. 

OWNER auth_id 

The owner of the tablespace. 

BUFFERPOOL BPn 

The default bufferpool associated with this tablespace. 

LOCKSIZE {ANY / PAGE / TABLE / TABLESPACE) 
The lock size parameter for the tablespace. 

CLOSE { YES / NO) 

The close action specification of the tablespace. 
DSETPASS password 

A data set password to be used for the tablespace. 

SEGSIZE number 

The segment size of the tablespace. 

ERASE { YES / NO} 

The erase action of the tablespace. 

VCAT catalog.name 

The volume catalog to be used by the tablespace. 
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CREATE TABLESPACE 



The default storage group for Uie tablespace. 

PF IC'TV nu.tber 

The primary allocation quantity of the tablespace. 

SEZvTY number 

The secondary allocation quantity of the tablespace. 

? C T F P. Z £ number 

The percent of free space to be left on each page of the 
tablespace upon create or reorganization. 

FREE PAGE number 

Defines that a free page will be added after every number 
pages upon tablespace creation or reorganization. 
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CREATE VJEW 

CREATE VIEW 



? E.* 7 E J E'a — v : e w_owne r - . - v ; e'.N_r.jre 



— rOLLT'.riS - ,-*-cc lurr.n — name — ' 

-'HECK CFT ION YES 

— NO 

— COMMENT - 'raring' 

—LABEL -'string' 

— rCOLCOMMENT — co lumn_name - 'string ' 

— 'COLLABEL - column_name - * st r ing ' — 

►—A3 SELECT -sub_se iect ■ : 

t Repea cable icem 

Description The CREATE VIEW statement defines a new view. 

Parameters view_owner . view_name 

The name and owner of the view being created. 

COLUMNS (column_name_l ist ) 

The names of the columns to be included in the view. 

CHECK OPTION { YES / NO) 

The check option to be used by the view. 

COMMENT 'string * 

The comment on the view. 

LABEL 'string' 

The label for the view. 

COLCOMMENT co lumn.name 'string' 

Defines a comment on column_name. 

COLLABEL column_name 'string' 

Defines a label for column_name. 



-> 
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CREATE VIEW 

i 

AS SELECT 3ub.:elec: 

Defines the SQL subselect statement used to create the view. 
The SELECT clause is required, and it must appear last in the 
z? eate view statement. 

Note: 

CDL does not support the w i th check option clause 
of SQL. Use check option {yes /no} instead. 
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DROP ALIAS 

DROP ALIAS 

: . r*FOP ALIAS -ai ia = _cwner - .-ai :3.-_r.arre 

Description The dpop alt as statement removes an alias definition. 

Parameters alias.owner . alias_name 

The owner and name of the alias to be dropped. 
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DROP DATABASE 



DROP DATABASE 



r-h^P TA7A3ASE-dazab3:-e_name ■ 



Description The drop database statement removes a database and all dependent 
10 objects. 

Parameters da:.abase_name 

The name of the database being dropped. 

15 
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DROP FOREIGN KEY 



DROP FOREIGN KEY 

DROP roRE TCN KEY-table_owner - . -lable.name - .-conscrainc.name 



Description The drop foreign key statement removes a referential imeenty 
constraint from a tabie. 

Parameters CabU_owner . table_name . constraint.name 

The fully-qualified name of the constraint to be dropped. 
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OROP INOEX 



DROP INDEX 



**— I>rOF IV.ZS'A — :ndex_c*r.e: — . - t ncex_nair.e 



Description The O&cp index statement removes an index from a table. 

PSTSmCterS Lr.dex_;>wner i ndex.name 

The name of the index being dropped. 
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DROP STOGHOUP 

DROP STOGROUP 

i 

j Of/y? STOOP CUP — s i roup_nane 



Description The DROP STOGROUP statement removes a storage group 
definition. 

Parameters s tog roup_name 

The name of the storage group being dropped. 
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DROP SYNONYM 



rfn c- s y r JOr fYM - - y ncnyrr._owne r - . - z y n o p. y m_ n j nne - 



Description The drop synonym statement removes a synonym definition. 

Parameters syncnym.owner . 3yncnym_name 

The name of the synonym being dropped. 
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OROP TABLE 



DROP TABLE _____ 

PhOT 7 As LEI — - a b 1 e_cwne r - . - lab 1 e_r.ame — k ^ \ 

! j 

Description The drop table statement removes a table definition. 

Parameters table_ovner . CabLe_name 

The name of the table being dropped. 
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DROP TABLESPACE 

I 

DROP TABLESPACE 

>» lT'-'-'P TABLES PACE! -da: JbdL-e^r.j.^e - . -lib * espare^r.ar.e : i 

i ' 



Description The drcf tables pace statement removes a tabiespace and alt 
dependent objects.. 

Parameters database_name . c afc> 1 esp-J ce_name 

The fully -qualified name o( the tabiespace being dropped. 
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DROP VIE\y 

DROP VIEW 

►* — DPO P 7 I E>* - v i e w_cwr. er-.-vi ew_name 

Description The drop v i ew removes a view definition. 

Parameters view_r*ner . view_name 

The fully-qualified name of the view being dropped. 
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Dash Commands 



CDL File Format 



CDL is imported into CHANGE MANAGEMENT from sequential. 
80-column files. Each command begins on a separate line, though 
commands may be continued on multiple lines. Command record 
formats are shown below. 



First Line of 
Commands 



COLUMN(S) 



USAGE 



1 

2-5 
6 

7-12 
13 

14-72 
73-80 



Must be dash 

Command name (e.g., DEST) 
Musi be blank 

Sequence number (zero-filled) 

Must be blank 

Free format command text 

Reserved 



Command 
Continuation Lines 



COLUMN(S) 



USAGE 



I 

2-72 
73-80 



Must be blank 

Free format command text 

Reserved 
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COL File Pormat 



There is no implied space or other token separator between column 72 
of one line and column 2 of the next. For example, if 'TABLE" 
appears in columns 68-72 of one line, and "SPACE" appears in 
columns 2-6 of the next, the GDI. scanner will read the token 
"TABLESPACE", and not the two words "TABLE" and "SPACE". 
Quoted strings can be continued from one line to the next. 

Command Termination 

Commands are terminated upon reaching either the end of the tile or 
the first following line which has a non-blank character in column one. 

Command Sequence 

The first three commands in a CDL file must be (in order) -time, 
-orcn, and -dest. 

Comments 

Comments are signalled by an asterisk "*" in column 1 , and terminate 
at the end of the line (column 80). Comments may appear anywhere in 
a file except in the middle of a command (since commands are 
terminated by a non-blank character in column one). 
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I -COL: Cha. Definition Language Statement 

-CDL: Change Definition Language Statement 

1 — 1 

\ - ; | 

Description The -col, command is used to introduce a CDL statement. 

Parameters -CDLDQstnum 

The symbol indicates that the -CDL token must be followed by two 
spaces, since scnum must appear in columns 7-12. 

cdl_statement 

A valid CDL statement as defined in the preceding section. 
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-OEST: Destination 



■DEST: Destination 



■ -OZSJZl'3 tnum — SS ID — subsy sCem_id -r-LOCAT rCN -r- 1 oca t ion_ id 

■■ * -J I * 



Description The -dest command defines the intended destination system of the 
CDL file, -dest must be the third command in a CDL file (alter 
-t ime and -orcn). 



75 



Parameters SSTD subsystem_id 

The destination subsystem of the CDL file. May be if unknown. 



20 
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30 
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45 



LOCATION location_id 

The destination location of the CDL file. May be if unknown. 



so 



CHANGE DEFINITION LANGUAGE (CDL) Reference 
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•-ORGN: Origin 



-ORGN: Origin 



►►--ORGNUscr.um — 5S ID -y-aubsystem.ui — LOCAT rON - j- locat ion_id 



►—RELEASE -T- ' sc r ing 



L 



Description The -orgn statement defines the system that originated the CDL. 

-orgn is a required command; it must appear after -T ime and before 

-DEST. 



Parameters SSID subsystem_id 

The origin subsystem of the CDL statements. May be if unknown. 

LOCATION locat Lon_id 

The origin location ID of the CDL. May be if unknown. 
RELEASE 'string' 

The version and release number of the DB2 system from which the 
CDL was generated. This is the release string returned from a DB2 

CALL ATTACH. 



Dash Command* 
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■TIME: Creation Time 



-TIME: Cr eation Time 

l _ 

j ►* — I* IMEDstr.um - ' t imes tamp_3 1 r i ng ' 



Description The -time statement defines the time and date the CDL Hie was 

created. -T ime must be the first executable command in the CDL file. 

Parameters * t imcstamp_str ing • 

A 26-byte string, in DB2 T imestamp format, that defines the date and 
time the CDL file was created. 
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APPENDIX B 
Change Definition Language 
BNF Crammer Definition 
With C Action Routines 

*< 

^include "acmp.h" 
#ifdef ACMG_OS2 
#include <memory.h> 
#endif 

#ifdef ACMG^MVS 
^include <string.h> 
#endif 



extern struct ACMP_P acmpdata; 
extern SHORT acmplineno; 
extern SHORT acmp_retcode; 

extern SHORT acmp_reason; /• REASON CODE FOR ERROR */ 
extern BOOL acmp^semerror; 

*> 

% prefix acmpc 
%union { 

struct ACMPJD strval; 

VCHAR 'idval; 

short nuxnvai; 

char byteval; 

struct ACMPJTN *tbnam; 

} 



%type 


< 


idval > 


stogrouppaxm 


%type 


< 


idval > 


shortid 


%type 


< 


idval > 


ownerparm 


9c type 


< 


idval > 


newsname 


%type 


< 


idval > 


newlname 


%type 


< 


idval > 


vcatpass 


%type 


< 


idval > 


volser 


%type 


< 


idval > 


dbasename 


%type 


< 


idval > 


passwparm 


%type 


< 


idval > 


longid 


%type 


< 


idval > 


locationid 


%type 


< 


idval > 


tgttype 



%type <numvaJ> freepageparm 
%type <numval> pet free par m 
%type <numval> priqtyparm 
%type <numval> secqtyparm 
%type <numval> partsparm 
%type <numval> segparm 
%type <byteval> unit 
%type < byteval > eraserule 
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Change Definition Language 
BNFCrammer Definition 
With C Action Routines 

%type <byteval> yesorno 
7c type <byteval> ixbpool 
<£type <byteval> ixbpoolspec 
Retype <byteval> bpoolparm 
<£type <bytevai> buflerpoolparm 
%type <byteval> beforeafter 
*£type <byteval> locksize 
*£type <byteval> lock par m 
<*type <byteval> close parm 
%type <tbnam> tb2name 
<£type <tbnam> tb3name 
%type <tbnam> table3name 



%token ADD AFTER ALIAS ALL ANY ALTER AS AUDIT AUDITSPEC BEFORE BIT 
%token BPO BP1 BP2 BP32K 

%token BUFFERPOOL CASCADE CATALOG CDL PCHAR CHANGES CHECK CLOSE 
CLUSTER 

%token COLLATE RULE PCOMMENT COLUMN COLUMNS 

%token COMMA CONSTANT CREATE CYL DATA DATABASE DATATYPE DATE DB2 

%token DECIMAL DEFAULT DELETE 

%token DEST DROP 

%token DSETPASS EDITPROC 

%tokea ERROR ERASE FIELDPROC FOR FOREIGN FLOAT 

%token FREEPAGE GRAPHIC INTEGER INDEX IS K KEY LABEL 

%token <strvaJ> LGDELID 

^token LOCATION 

%token <strval>LOCID 

%token LPAKEN LOCKSIZE 

%token <3trvai> LONGID 

%token LONGVARCHAR LONGVARGRAPHIC MGPR MOVE 

%token NAME NO KODSETPASS NOVCATPASS NONE NOT NULLB 

%token <numvaJ> NUMBER 

%token NUMPARTS OF OFF ON 

%token ORDERED ORGN OPTION 

%token OWNER PAGE 

%token PART 

*token PCTFREE PERIOD PRIMARY PRIMARYTB PRIMARYVOL PRIQTY PROG 
%token <atrval> QUOTEDSTR 

%token REFERENCETB RELEASE REMOVE REPLACE RESTRICT RPAREN SECQTY 
SEGSI2E * 
%token SELECT SEMIC SEQUENCE SET SCPR 
betoken <strval> SHDELID 
% token <strval> SHORTID 
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Change Definition Language 
BNF Grammer Definition 
With C Action Routines 
<*token SMALLINT SRNM SRTY SSID STOGROUP SYNONYM SUBPAGES 
betoken TABLE TABLES PACE TIME TIMESTAMP 

<*token TRNM TRK TRTY TYPE UNIQUE UNITS WAS WITH VALIDPROC 
<7rtoken VALUES VARCHAR VARGRAPHIC 
%token VCAT VCATP VCATPASS VIEW 
Cfrtoken <strvai> VOLSER 
fttoken VOLUMES YES 

%start program 

%<* 

program 
: statement 

| program SEMIC statement 
| error 

{ 

/• CLEAN UP PARSER DATA STRUCTURES FOR NEXT STMT V 
acmpclea ( &acmpdata ); 

} 

| SEMIC 



statement 

: CDL stnum stmttype 
| commandstmt 

stnum 

: NUMBER 
{ 

acmplineno - $1; 

> 



stmttype 

: ALTER alterstmt 
| CREATE createstmt 
| DROPdropstmt 
[ commentstmt 
| labels tmt 



commandstmt 

: PROG stnum QUOTEDSTR 
{ 

mem set ( acmpdata.ptree*> header, progn am e, * \ 
sizeof(CHAR56> - 1 ); 
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Change Definition Language 
BNF Crammer Definition 
With C Action Routines 
if ( $3.11en > sizeoftCHAK56) ) 
{ 

$3.1Ien = sizeoftCHAR56>; 

> 

memcpy ( acmpdata.ptree->header.progname, $3.str, 
$3. lien ); 

ac m pda ta.p tree- > header, progn am ef si zeof(CHAR56) - I J = AO*- 

I ORGN stnum SSID shortid LOCATION shortid RELEASE QUOTEDSTR 

acmpvtn < acmpdata.ptree-> header. origssid, $4 );■ 
acmpvtn ( acmpdata.ptree->header.origloc, $6 ); 
mem set ( ac m pda ta. p tree- > header. db release, ' 

sizeoff CHAR10 ) - 1 ); 
if ($8.Ilen > sizeof(CHARlO) ) 
{ 

$8.Uen = sizeof(CHAR10); 

> 

memcpy ( acmpdata.ptree->header.dbrelease, $8.str, 
$8.Uen); 

acmpdata.ptree->header.dbrelease(sizeonCHARlO) - 1] ^ 

\0'; 

'} 

I DEST stnum SSID shortid LOCATION shortid 

{ 

acmpvtn ( acmpdata.ptree-> header .destssid, $4 ); 
acmpcid ( acmpdata.ptree-> header .destloc, $6 )• 

} 

| SCPR stnum shortid PERIOD longid TYPE longid 

acmpvtn C acm pda ta.p tree- > header. scopequai, $3 ); 
acmpcid ( acmpdata.ptree-> header. scopename, $5 ); 
acmpvtn C acmpdata.ptree-> header, scope type, $7 ); 

| MGPR stnum shortid PERIOD longid 

{ 

acmpvtn ( acmpdata.ptree->header.migprofqual f $3 ); 
acmpcid ( acmpdata.ptree->header.migprofname, $5 ); 

} 

| SRNM stnum QUOTEDSTR 

{ 

memset ( acmpdaU.ptree->header.sourceQame, ' 

sizeoft CHAR56 ) - 1 ); 
if < $3.Hen > sizeof[CHAR56) ) 
{ 
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10 



20 



35 



Change Definition Language 
iBNF Grammer Definition 
With C Action Routines 
$3. Hen = sizeof(CHAJR56); 

> • 

memcpy ( acmpdata.ptree^header.sourcename, 

$3.str, $3. lien); 
acmpdata.ptree-> header, source nam elsizeof(CHAR56) - ll 

\0'; 

} 



| TRNM stnum QUOTEDSTR 
{ 

mem set ( acmpdata.ptree->header.trgtname, ' 
sizeof(CHAR56) - I ); 
75 if ( $3, lien > sizeof[CHAR56) ) 

{ 

$3.llen = sizeof(CHAR56); 

} 

memcpy ( acmpdata.ptree-> header. trgtname, 

$3.str, $3. lien ); 
acmpdata.ptree-> header. trgtname(sizeof(CHARS6) - 1] - 
\0'; 

> 

| SRTY stnum tgttype 
{ 

25 acmpvtn( acmpdata.ptree->header.sourcetyp>e 1 $3 ); 

y 

| TRTY stnum tgttype 
{ 

acmpvtn ( acmpdata.ptree-> header, trgttype, $3 ); 

30 y 

| TIME stnum QUOTEDSTR 
{ 

mem set ( acmpdata.ptree-> header, timestamp, ' \ 

sizeof ( CHAR28 ) - 1 ); 
if ( $3.1Ien > sizeoflCHAR28) ) 
{ 

$3.11en = sizeof(CHAR28); 

} 

memcpy ( acmpdata.ptree-> header, timestamp, $3.str, 
$3. Ilea ); 

40 acmpdata.ptree- > header. timestampfsizeo f( CHAR28 ) - l| = 

} 



45 tgttype 

: shortid 



{ $$ = $1;} 
I shortid DB2 CATALOG 
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Change Definition Language 
BNF Gram in er Definition 
With C Action Routines 

{$$=$!;} 

alterstmt 

: aitdatabase 
| alttablespace 
| alttable 
| altforeignkey 
| altindex 
| altview 
| altsynonym 
| altalias 
| altstogroup 

createstmt 
: crdatabase 
| cr tables pace 
| crtable 
| cr foreign key 
| crindez 
| crview 
| crsynonym 
I craiias 
| crsto group 



dropstmt 
: dpdatabaae 
| dptablespace 
| dptabie 
| dpfo reign key 
| dpindez 
| dp view 
| dpsynonym 
| dpaJiaa 
| dpsto group 
| dpcomment 
| dptabel 



r 

ALTER DATABASE 

V 

aitdatabase 

: DATABASE shortid alterdblist 
{ 
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Change Definition Language 
BNF Grammer Definition 
With C Action Routines 

acmp_reason = acmpdatb ( ACMG_ALTER. $2, fcacmpdata ); 
if ( acmp.reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

} 



alterdblist 

: aJterdbparin 

| alterdblist alterdbparm 

alter dbparm 
: newsQ&me 

{ 

acmp_reason = acmpsnamC ACMG_DBD, $1, &acmpdata ); 

if ( acmp_reason ! = ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

> 

| owner par m 

( 

acmp_reason — acmponam ( ACMG_DBD, $1, &acmpdata ); 

if ( acmp_reason != ACMG_RC_OFO 

{ 

ACMPCERROR; 

> 

} 

| create parm 



/• 

ALTER TABLESPACE 

V 

alttablespace 

: TABLESPACE tsname Uparmlist 
{ 

acmpjreason = acmptabs( ACMG_ALTER, &acmpdata ); 

if ( acmp_reason ! = ACMG_RC_OK ) 

{ 

ACMPCERROR; 
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Change Definition Language 
BNF G rammer Definition 
With C Action Routines 

) 

> 



tsparmlist 

: alter tsparm 

| tsparmlist a Iter tsparm 



a Iter tsparm 
: newsname 

{ 

acmp_ reason = acmpsnamt ACMGJTSD, $1, fcacmpdata ); 

if ( acmp_ reason != ACMG RCOK) 

{ 

ACMPCERROR; 

} 

> - 

| dbasename 

{ 

/• ALLOCATE THE TABLES PACE OBJECT, IF NECESSARY 
acmp_retcode - acmpaJoc ( ACMG_TSD, &acmpdata ); 
ifCacmp retcode EQ ACMG_RC OK) 
{ 

/• SEE IF NEW DATABASE ALREADY SPEC'ED V 
if ( acmpdata.tabsp->ndbn_pv->data[0] EQ " ) 

{ 

/• STORE THE NEW NAME PARAMETER •/ 
acmpcid ( acmpdata.tabsp->ndbn_pv, $1 ); 
} 

else 
{ 

acmpreason = ACMG SPECERR; 
ACMPCERROR; 

} 

} 

else 
{ 

acmp_reason = ACMG SPACE; 
ACMPCERROR; 

} 

> 

| parts pec 
| tsparm s 
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Change Definition Language 
BNF Grammer Definition 
With C Action Routines 



tsparms 

: buflerpoolparm 

{ 



lockparm 



close parm 



acmp_reason = acmpbfpl t ACMG_TSD, $t» &acmpdata ); 

if ( acmp_reason ! = ACMG_RC_OK ) 

{ 

ACMPCERROR; 



} 



{ 



acmp_ reason = acmplksz( $1, &acmpdata ); 

if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 



} 



} 



{ 



acmp_reasoa = acmpclr( $1, &acmpdata ); 
if ( acmp_reason !~ ACMG_RC_OK) 
{ 

ACMPCERROR; 

> 



} 



| passwparm 



{ 



acmp_reason - acmppas( $1, &acmpdata >; 
if ( acmp_reason != ACMG,RC_OK ) 
< 

ACMPCERROR; 



| segparm 

{ 

acmp_ reason = acmpseg( $1, &acmpdata ); 
if ( acmp_reason != ACMG_RC_OK) 
{ 

ACMPCERROR; 

} 

} 

1 eraserule 
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Change Definition Language 
BNF G rammer Definition 
With C Action Routines 

{ 

acmp_ reason = acmperas( $1, &acmpdata ); 

if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

> 

| ownerparm 

{ 

acmp_ reason = acmponam C ACMGJTSD, $1, &acmpdata ); 

iff acmp reason != ACMG_RC OK ) 

{ 

ACMPCERROR; 

} 

> 

| p&rtsparm 

{ 

acmp_reason = acmppts( $1, &acmpdata ); 
if ( acmp_reason ! = ACMG RC OK ) 
{ 

ACMPCERROR; 

I 

} 



/• 

TABLESPACE PARTS SPECIFICATION 

•/ 

parts pec 
: alter part 
| addpart 
| droppaxt 

alter part 

: ALTER PART NUMBER LPAREN partparmlist RPAREN 
{ 

acmp_reason = acmpcptf ACMG_ALTER. ACMG_ALTER, 
$3, &acmpdata ); 
if ( acmp reason != ACMG RC OK) 
{ 

ACMPCERROR; 

} 
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Change Definition Language 
BNF'Grammer Definition 
With C Action Routines 



add part 

: ADD PART beforeafter NUMBER LPAREN partparmlist RPAREN 

{ 

/• ADD THE PARAMETERS TO THE PARTS STRUCTURE V 
acmpdata.parts->drct = $3; 
acmpdata.parts->trgt — $4; 

acmp_reason = acmpcpt( ACMG_CREATE, ACMG_ALTER, 
$4, &acmpdata ); 
if ( acmp_reason ! = ACMG_RC_OK ) 
{ 

ACMPCERROR; 

> 

/• RESET PART NUMBER TO ZERO •/ 
acmpdata.tabsp->part_p->nmbr = 0; 

> 



droppart 

: DROP PART NUMBER 

{ 

/* ALLOCATE A PARTS OBJECT */ 

acmp_retcode - acmpaloc ( ACMG_PTD. &acmpdata ); 

if ( acmp retcode EQ ACMG_RC OK ) 

{ 

acmp_reason = acmpcpt( ACMG JDROP. ACMG_ALTER, 
$3, &acmpdata ); 
if ( acmp_reason 1= ACMG_RC_OK ) 
{ 

ACMPCERROR; 

> 

} 



partparmlist 
: partparm 

| partparmlist partparm 



partparm 

; vcatparms 
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Change Definition Language 
BNF Grammer Definition 
With C Action Routines 



10 



15 



25 



30 



40 



stogroupparm 
{ 



a c en p_ reason = acmpstgp ( ACMG_PTD, $1, &acmpdata ) 

if( acxnp reason != ACMG RC_OK > 

{ 

ACMPCERROR; 

} 

} 



| pnqtyparm 

{ 

acmp_ reason = acmpprqt $1, &acmpdata ); 
if ( acmp reason f= ACMG RC OK ) 
{ " 
20 ACMPCERROR; 

> 

} 



| secqtyparm 

< 

acmp_reason = acmpsec( $1, &acmpdata ); 
if (acmp reason != ACMG RC OK) 
{ 

ACMPCERROR; 

} 

} 



| pc t free par m 

{ 

acmp reason = acmppcfr( $1, fcacmpdata ); 
35 if ( acmp reason != ACMG_RC OK ) 

{ 

ACMPCERROR; 

> 

} 



freepagepaxm 
{ 



acmp_reason = acmpfrpgt $1, &acmpdata ); 

if (acmp reason != ACMG RC_OK) 

{ 

45 ACMPCERROR; 

} 

} 
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Change Definition Language 
$NF Grammer Definition 
With C Action Routines 



ALTER TABLE 



alttable 

: TABLE tb2name altertblist 



altertblist 

: altertbparm 

| altertblist altertbparm 

altertbparm 

: tbname2parm 
| owner par m 
| d base name 
| tsparm 
| edit par m 
| validparxn 
I audit par m 
| altercolumn 
| prikeys 
• 

/* 

ALTER TABLE COLUMNS 

•/ 



altercolumn 

: ALTER COLUMN longid LPAREN altcolspec RPAREN 
j DROP COLUMN longid 

I ADD COLUMN longid beforeafter longid LPAREN colspec RPAREN 



altcolspec 

: altco 1 spec par m 

| altcolspec altcolspecparm 



altcolspec par m 
: seqparm 
| type par m 
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Change Definition Language 
BNF Crammer Definition 
With C Action Routines 

| forbitspec 
| fieldprocspec 
I nullrule 
| newlname 
| moveparm 

coispec 

: colspecparm 

| coispec colspecparm 

colspecparm 
: seqparm 
| type par m 
| forbitspec 
| fieldprocspec 
| nullrule 



moveparm 

: MOVE beforeafter longid 

/• ' 

ALTER TABLE PRIMARY KEYS 



prikeys 
: dropkey 
| addkey 
J alter key 

dropkey 

: DROP PRIMARY KEY 

addkey : 

ADD PRIMARY KEY LPAREN keycolumnlist RPAREN 

keycolu inn list 
: longid 

| keycolumnlist COMMA longid 
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( Change Definition Language 
BNF G rammer Definition 
With C Action Routines 

alterkey 

: ALTER PRIMARY KEY LPAREN keycolumnlist RPAREN 



ALTER FOREIGN KEY 

V 



altforeignkey 

: FOREIGN KEY fknamespec FOR tb2name alterclauses 



alterclauses 
: alterfkparm 
| alterclauses alterfkparm 

alterfkparm 
: newfkname 
| referencetb 
| fkcollist 
| colcolliat 
| deletespec 

| PRIMARYTB tb2name 

newfkname 

: NAME NONE 
| NAME shortid 

colnamelist 
: longid 

| colnamelist COMMA longid 
colcollist 

: WAS COLUMNS LPAREN colnamelist RPAREN 



fkcollist 

: COLUMNS LPAREN colnamelist RPAREN 
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Change Definition Language 
BNF Grammer Definition 
With C Action Routines 

■• 

ALTER INDEX 

•/ 

altindex 

: INDEX ixname alterixparms 

alterixparms 
: alterixparm 

| alterixparms alterucparm 

alterlxparm 
: table2naxne 
| newlname 
| ownerpaxm 
| uniquerule 
| clusterspec 
| subpages 
| ixb pool spec 
| Lx parts pec 
| alter ixcol 
| closeparm 
| passwparm 
i 

/• 

INDEX COLUMN SPECS 

7 



alterixcol 

: ADD COLUMN longid beforeafter longid addLxcolparms 
| DROP COLUMN longid 

| ALTER COLUMN longid LPAREN altixcoiparms RPAREN 

altixcoiparms 
: altixcolparm 

| altixcoiparms altixcolparm 

altixcolparm 

: commonixcolparm 
| newlname 
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Change Definition Language 
1 BNF Grammer Definition 
With C Action Routines 

addixcolparms 

: commonixcolparm 

{ addixcolparms commonixcolparm 



commonixcolparm 
: COLLATERULE 
| eraserule 



ixpartspec 

: ADD PART NUMBER ixpartparms 
| ALTER PART NUMBER ixpartparms 
| DROP PART NUMBER 

ixpartparms 
: ixpartparm 

| ixpartparms ixpartparm 

ixpartparm 

: VALUES LPAREN constlist RPAREN 

| vcatparms 

[ stogroupparm 

| freepageparm 

| pet free par m 

[ priqtyparm 

[ secqtyparm 

| eraserule 



/* 

ALTER VIEW 

•/ 

altview 

: VIEW tb2name altvwparms 



altvwparms 
: altvwparm 

| altvwparms altvwparm 
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Change Definition Language 
BNF Gramtner Definition 
With C Action Routines 
" this part needs work by JEO, what parameters should be provided for 
constructing view text V. V 

altvwparm 
: addvwcol 
| delvwcol 
| altervwcol 
| checkopt 
| viewtext 
| newlname 
| ownerparm 

| no owner rrrr> ■/ 

addvwcol 

: ADD COLUMN longid beforeafter longid 

altervwcol 

: ALTER COLUMN longid newlname 

delvwcol 

: DROP COLUMN longid 

/* 

ALTER SYNONYM 

*/ 



altsynonym 

: SYNONYM tb2name aitersynparms 
{ 

/• STORE THE SYNONYM NAME V 
acmpcid ( acxnpdata.syns->aame _pv, $2->tbna ); 
acmpcid ( acmpdata.syns->ownr_pv, $2-> tbow ); 
acmpdata.syn3->clvl = ACMG_ALTER; 

acmp_reason = acmpsyns ( acmpdata.ptree f acmpdata.syris ); 
if ( acmp reason != ACMG RC OK ) 
{ " 
ACMPCERROR; 

} 

} 



aitersynparms 
: aitersynparm 
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Cjhange Definition Language 
BNF Grammer Definition 
With C Action Routines 

| altersynparms altersynparm 



Itersynparm 
: TABLE tb2name 
{ 

a cm p_ reason = acmpaloc I ACMG_SYD, &acmpdata ); 

if i acmp_reason EQ ACMG_RC_OK ) 

{ 

acmpcid ( acmpdata.syns->tbow_pv, $2->tbow ); 
acmpcid ( acmpdata.syns->tbna_pv, $2->tbna ); 

else 
{ 

ACMPCERROR; 

} 

} 

| newlnazne 
{ 

acmp_reason = acmpsnam ( ACMG_SYD, $1, &acmpdata ); 

if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

} 

| owuerpaxm 
{ 

acmp_ reason = acmponam ( ACMG SYD, $1, &acmpdata ); 
if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

> 



ALTER ALIAS 



ltalias 

: ALIAS tb2name altalpaxms 

{ 

/• COPY THE ALIAS NAME •/ 
acmpcid ( acmpdata.alias->ownr_pv, $2->tbow ); 
acmpcid ( acmpdata.alia3->name_pv, $2->tbna >; 
acmpdata.alias->clvl « ACMG_ALTER; 
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Change Definition Language 
BNF Grammer Definition 
With C Action Routines 

- STORE THE ALIAS NODE IN THE PARSE TREE V 
acmp_reason = acmpaliat acmpdata.ptree, acmpdata. alias >; 
if < acmp_reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

} 

} 

a ltal parens 
: altalparm 

| altaipaxma altalparm 

altalparm 
: table3name 
{ 

acmp_reason = acmpaloc ( ACMG_ALD, fcacmpdata ); 

if ( acmp_reason EQ ACMG RC_0~K ) 

{ 

if ($l->tbloc! = NULL) 
{ 

acmpcid ( acmpdata.alias-> tblc_pv, $l->tbloc )* 

} 

acmpcid ( acmpdata.a!ias-> tbow_pv, $l->tbow ); 
acmpcid ( acmpdata.alias->tbna_pv, $l->tbna )* 

} 

else 
{ 

ac'mp_reason = ACMG SPACE; 
ACMPCERROR; 

} 

acmgfree ( $1 ); 

> 

| ownerparm 

{ 

acmp_reason = acmponam ( ACMG_ALD, $1, & acmpdata ); 

if ( acmp_ reason ! = ACMG RC OK ) 

{ 

ACMPCERROR; 

} 

> 

| newlname 
{ 

acmp_reason » acmpsnam ( ACMG_ALD, $1, fcacmpdata ); 

if ( acmp_reason != ACMG RC OK ) 

{ 
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. ACMPCERROR; 
} 

> 



/• 

ALTER STOGROUP 

V 

altstogroup 

: STOGROUP stogroupname altstogroupparms 

{ 

acmp_reason = acmpstog ( ACMG_ALTER t &acmpdata ); 

if < acmp_reason !=» ACMG_RCJDK ) 

{ 

ACMPCERROR; 

} 

} 



altstogroupparms 
: altstogroupparm 

| altstogroupparms altstogroupparm 



altstogroupparm 
: newsname 
{ 

acmp_reason =* acmpsnamt ACMG_SGD f $1, &acmpdata ); 

if ( acmp_reason ! = ACMG_RC_OK) 

{ 

ACMPCERROR; 

> 

} 

| owner par m 

{ 

acmp_reason = acmponam( ACMG^SGD, $1, &acmpdata ); 
if I acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

} 
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I VOLUMES LPAREN vollist RPAREN 
{ 

acmp_reason = acmpvlstt ACMG_SGD, ACMG.REPLACE. fcacmpdata ); 
if ( acmp_reason != ACMG_RC OK ) 
{ 

ACMPCERROR; 

> 

} 

| stogvcat 

;s ; 

stogvcat 

: VCAT shortid 
< 

2 0 acmp_ reason = acmpvcatC ACMG_SGD, $2, fcacmpdata ); 

if ( acmp reason != ACMG_RC_OK ) 
{ 

ACMPCERROR; 

> 

} 

25 

| vcatpass 
{ 



5 



10 



acmp_reason = acmpvps( ACMG_SGD, $1, &acmpdata ); 

if ( acmp reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

} 

> 



/• 

CREATE DATABASE 



crdatabase 

: DATABASE shortid createlist 
{ 

acmp.retoode = acmpdatb ( ACMG_CREATE, $2, fcacmpdata ); 

if (acmp retcode ! = ACMG RC OK) 

{ 

ACMPCERROR; 

} 



55 
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| DATABASE shortid 
< 

aemp_retcode - acmpaloc ( ACMG_DBD, &acmpdata ); 
if ( acmp^retcode EQ ACMG_RC_OK ) 

{ 

acmp_retcode = acmpdatb ( ACMG_CREATE, $2, &acmpdata ); 
if ( acmp_retcode != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

> 

else 
{ 

acmp_retcode = ACMG_SPACE; 
ACMPCERROR; 

} 

} 



createlist 

: createparm s 

| createlist createparms 



createparxns 
: ownerpartn 

{ 

acmp_ reason = acmponam ( ACMG_DBD, $1, Scacmpdata ); 

if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

> 

> 

| createparm 



createparm 

: stogroupparm 
{ 

acmp_ reason = acmpstgp ( ACMG^DBD, $l f &acmpdata ); 

if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 
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} 



buflferpoolparm 
{ 

acmp_ reason = acmpbfpl t ACMG_DBD, $1, fcacmpdata ); 

if ( acmp reason != ACMG RC OK) 

{ 

ACMPCERROR; 

} 

} 



CREATE TABLES PACE 



crtablespace 

: TABLESPACE tsname createtslist 
{ 

acmp_reason = acmgdfp< acmpdata.tabsp ); 

if ( acmp reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

> 

acmp_ reason = acmptabs( ACMG_CREATE, &acmpdata ); 

if ( acmp reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

> 

} - 

| TABLESPACE tsname 

{ 

acmp reason = acmptabsC ACMG_CREATE, &acmpdata ); 

if ( acmp reason 1= ACMG RC OK ) 

{ 

ACMPCERROR; 

> 

} 
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createtslist 

: createtsparm 

I createtslist createtsparm 

createtsparm 
: tsparms 
| crpartspec 



crpartspec 

: PART NUMBER LPAREN partparmlist RPAREN 

{ 

acmp_reason = acmpcpt( ACMG_CREATE, ACMG_CREATE. 
$2, &acmpdata ); 
if ( acmp reason != ACMG RC OK) 
{ 

ACMPCERROR; 

} 

> 



/• 

CREATE TABLE 

V 

crtable 

: TABLE tb2name createtblist 



createtblist 

: createtbparm 

| createtblist createtbparm 

createtbparm 
: dbasename 
| tsparm 
| editparm 
| validparm 
| auditparm 
| crprikey 
| createcolspec 
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** CREATE TABLE COLUMNS SPEC 

createcolspec 

: COLUMNS LPAREN collist RPAREN 

collist 
: coldef 

| collist COMMA coldef 

coldef 

: longid colparmlist 

colparmlist 
: colparm 

| colparmlist colparm 
* 

colparm 

: typeparm 
I FOR BIT DATA 
| fieldprocspec 
| nuiirule 

CREATE TABLE PRIMARY KEY 

crprikey 

: PRIMARY KEY LPAREN keycolumnlist RPAREN 



CREATE FOREIGN KEY 

•/ 

crforeignkey 

: FOREIGN KEY fknamespec FOR tb2name addclauses 

addclauses 
: addflcparm 



i 
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| addclauses addfkparm 

addfkparm 
: referencetb 
| flccollist 
| delete spec 



CREATE INDEX 



crindex 

: CREATE INDEX ixname createixparms 

createixparms 
: create ixparm 

| createixparms createixparm 

create ixparm 
: table2name 
| uniquerule 
| clusterspec 
| subpages 
| ixbpoolspec 
| crixpart 
| createixcol 
| close parm 
| passwparm 



CREATE INDEX COLUMNS 

•/ 

createixcol 

: COLUMNS LPAREN ixcollist RPAREN 



ixcoltist 
: longid 

| addixcolparms COMMA longid 
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CREATE INDEX PARTS 



cnxpart 

: PART NUMBER ixpartparms 



CREATE VIEW 

*/ 

crview 

: VIEW tb2name crvwparms 

crvwparms 
: crvwparm 

| crvwparms crvwparm 

crvwparm 
: co Id esc 
| checkopt 
| viewtext 



CREATE SYNONYM 

•/ 

crsynonyro 

: CREATE SYNONYM tb2name TABLE tb2name 
{ 

/• ALLOCATE THE SYNONYM TEMPORARY OBJECT 
acmp_reason = acmpaloc ( ACMGSYD, fcacmpdata ); 
if ( acmp_reason EQ ACMG RC OK ) 

{ 

/• STORE SYNONYM PARAMETERS V 
acmpcid ( acmpdata.syns->name_pv, $3->tbna ); 
acmpcid ( acmpxiata.syu3->ownr_pv, $3->tbow ); 
acmpcid ( acmpdata.syris->tbna_pv, $5->tbna ); 
acmpcid ( acmpdata.syns->tbow_pv, $5->tbow ); 
acmpdata.syns->clvi = ACMG^CREATE; 
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• STORE NODE IN PARSE TREE V 

acmp_reason - acmpsyns( acmpdata.ptree. acmpdata.syns ); 
if i acmp_reason != ACMG_RC_OfC ) 

{ 

ACMPCERROR; 

> 

> 

else 
{ 

acmp_reason = ACMG SPACE; 

} 



CREATE ALIAS 

•/ 

c raii as 

: ALIAS tb2name table3name 
{ 

/• ALLOCATE THE ALIAS TEMPORARY OBJECT V 
acmp_reason = acmpaloc ( ACMG_ALD, &acmpdata ); 
if ( acmp_reason EQ ACMG_RC_OK ) 
{ 

/• STORE ALIAS PARAMETERS •/ 
acmpcid ( acmpdata.alias->name_pv, $2->tbna ); 
acmpcid ( acmpdata.alias->ownr_pv, $2->tbow ); 
acmpcid ( acmpdata.alias->tbna_pv, $3->tbna ); 
acmpcid ( acmpdata.alias->tbow_pv ? $3->tbow ); 
acmpcid ( acmpdata.alias->tblc_pv, $3->tbloc ); 
acmpdata.alias->clvl = ACMG_CREATE; 

/• STORE THE ALIAS OBJECT IN THE PARSE TREE •/ 
acmp reason — acmpaiia ( acmpdata.ptree, 

acmpdata.alias ); 
if ( acmp_ reason != ACMG_RC_OK > 

{ 

ACMPCERROR; 

} 

} 

else 
{ 

acmp_reasoQ = ACMG_SPACE; 
ACMPCERROR; 
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CREATE STOGROUP 

*/ 

crsto group 

: STOGROUP stogroupname stogroupparms 

acmp_reason = acmpatog ( ACMG^CREATE, fcacmpdata )• 
if < acmp_reason ! = ACMG RC OK) 
{ " " 

ACMPCERROR; 

} 

> 



stogroupparms 
: s to group 

| stogroupparms s to group 

sto group 
: stogvcat 

| VOLUMES LPAREN vollist RPAREN 
{ 

acmp_reason = acxnpvlstf ACMGJ5GD, ACMG REPLACE, &acmpdata )■ 
if ( acmp reason != ACMG RC OK ) 
{ ~ 
ACMPCERROR; 

} 

} 

| ownerparm 

{ 

acmp_reason = acmponamt ACMG_SGD. $l t &acmpdata ); 
if ( acmp reason != ACMG RC OK) 

{ 

ACMPCERROR; 

> 



COMMENT ON 



i 
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commentstmt 

: PCOMMENT ON objectcomm 



objectcomm 

: TABLE tb2name IS QUOTEDSTR 
| ALIAS tb2name IS QUOTEDSTR 
| COLUMN OF tb2name LPAREN colcomlist RPAREN 



colcomlist 
: columncom 

| colcomlist COMMA columncom 



columncom 

: longid IS QUOTEDSTR 



/* 

LABEL ON 

V 

labels tmt 

: LABEL ON objectcomm 



DROP OBJECTS 

V 

dpdatabase 

: DATABASE shortid 
{ 

acmp_retcode « acmpaloc( ACMG_DBD P &acmpdata ); 

if ( acmp_retcode EQ ACMG_RC_OK) 

{ 

acmp_reason =° acmpdatb ( ACMG_DROP, $2, &acmpd 
if ( acmp_reason 1= ACMG_RCJDK) 

{ 

ACMPCERROR; 

} 

> 

else 
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{ 

acmp_reasoo = ACMGSPACE; 
ACMPCERROR; 

> 

> 



dptablespace 

: TABLESPACE tsname 
{ 

acmp_ reason = acmptabs( ACMG_DROP, &acmpdata ); 

if ( acmp_reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

> 

} 



dptable 

: TABLE tb2name 



dpfo reign key 

: FOREIGN KEY fknamespec FOR dpflcparms 



dpfkparms 
: referencetb 
| colcollist 



dpview 

: VIEW tb2name 



dpindex 

: INDEX ben am e tabie2name 



dpsynonym 

: SYNONYM longid 
{ 

acmp_retcode = acmpaioc ( ACMG_SYD, &acmpdata ); 

if ( acmp_retcode EQ ACMG_RC_OK ) 

< 
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/* STORE GLOBAL AUTHID AS OWNER •/ 
acmpownr ( acmpdata.syns->ownr_pv, fcacmpdata ); 

/• STORE THE NAME AND ADD TO PARSE TREE •/ 
acmpdata.syns->clvl = ACMG_DROP; 
acmpcid ( acmpdata.syns->name _pv, $2 ); 
acmp_reason = acmpsyns ( acmpdata.ptree, 

acmpdata :syn s ); 
if ( acmp_reason != ACMG_RC_OK ) 
{ 

ACMPCERROR; 

} 

> 

else 

{ 

acmp_ reason = ACMG_SPACE; 
ACMPCERROR; 

} 

> 



dpalias 

: ALIAS tb2name 
{ 

acmp retcode = acmpaloc ( ACMG_ALD, & acmpdata ); 
if ( acmp_retcode EQ ACMG_RC_OK) 

{ 

/• STORE THE NAME V 

acmpcid ( acmpdata.aHas->name_pv, $2->tbna ); 
acmpcid ( acmpdata.alias->ownrjpv, $2->tbow ); 
acmpdaU.aliaa->clvl = ACMG_DROP; 

/• STORE THE OBJECT IN PARSE TREE V 
acmp^reason = acmpalia ( acmpdata.ptree, 

acmpdata. alias ); 
if ( acmp_ reason : = ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

} 

else 
{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 

> 

} 
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dps to group 

: STQGROUP stogroupname 
( 

acmp_retcode - acmpaloct ACMG_DBD ( fcacmpdata ); 

if(acmp reteode EQ ACMG RC OK ) 

{ 

acmp_ reason acmpstog ( ACMGDROP, fcacmpdata 
if ( acmp_reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

} 

> 

else 
{ 

acmpjreason = ACMG SPACE; 
ACMPCERROR; 



dpcomment 

: PCOMMENT ON dpobject 



dpobject 

: TABLE tb2name 
| ALIAS tb2name 

| COLUMN OF tb2name LPAREN coinamelist RPAREN 



dplabel 

: LABEL ON dpobject 



MISCELLANEOUS COMMAND PARAMETERS 

V 
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audttparm 

: AUDIT AUDITSPEC 



beforeafter 

: BEFORE { $$ « ACMG.BEFORE; } 

I AFTER { $$ = ACMG_AFTER; } 



bu fferpoo 1 par m 

: BUFFERPOOL bpoolparm { $$ = $2; } 



bpoolparm 

.Lxbpool {$$ = $1;} 

| BP32K { $$ = ACMG_BP32K; } 



checkopt 

: CHECK OPTION yesorno 



close parm 

: CLOSE yesorno { $$ = $2; } 



clusterspec 

: CLUSTER yesorno 



coldesc 

: COLUMN longid NUMBER 
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constlist 

: CONSTANT . 

I constlist CONSTANT 



datatype 

: PCHAR LPAREN NUMBER RPAREN 
| INTEGER 

| FLOAT LPAREN NUMBER RPAREN 
I LONGVARCHAK 

i VARCHAR LPAREN NUMBER RPAREN 
| SMALLINT 

| GRAPHIC LPAREN NUMBER RPAREN 

| VARGRAPHIC LPAREN NUMBER RPAREN 

| LONGVARGRAPHIC 

I DATE 

| TIME 

I TIMESTAMP 

i DECIMAL LPAREN NUMBER COMMA NUMBER RPAREN 
| DECIMAL LPAREN NUMBER RPAREN 

dbasename 

: DATABASE shortid { $$ $2; } 



deletespec 

: ON DELETE deleterule 



deleterule 
: CASCADE 
I DELETE 
| SET NULLB 



empty 



editparm 

: EDITPROC shortid 
I NO EDITPROC 
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eraserule 

: ERASE yesorno 



{ $$ = $2; } 



fieldprocspec 

: FIELDPROC shortid 

| FIELDPROC shortid constlist 



fknamespec 
: empty 
| shortid 



forbit 

: FOR BIT DATA 



forbitoff 

: forbit OFF 



forbitspec 
: forbit 
| forbitoff 

freepageparm 



$$ = $2* 

CHKRANGEC $$, 0, ACMG_MAXFRPG t ACMG_FREE PRANG E ); 
if ( acmp_reason ! = ACMG_RC_OK ) 



: FREEPAGE NUMBER 
{ 



{ 



ACMPCERROR; 



ixbpool 



:BP0 
| BPl 
| BP2 



{ $$ « ACMG.BPO; } 
{ $$ » ACMG_BP1; } 
{ $$ = ACMG_BP2; } 



111 



EP 0 534 466 A2 



Change Definition Language 
BNF Crammer Definition 
With C Action Routines 



ixbpoolspec 

: BUFFERPOOL ixbpool { $$ = $2; } 



ixname 
: tb2name 



lockparm 

: LOCKSIZE locksize { $$ = $2; > 



locksize 
: ANY 
| PAGE 
I TABLE 
| TABLESPACE 



{ $$ = ACMG_ANY; } 
.{ $$ = ACMG_PAGE; } 
{ $$ = ACMcTtABLE; > 

{ $$ = ACMGJTABLESPACE; } 



longid 

: LONGID 

{ 

$$ = acmpalid ( &($1),0. TRUE ); 
. if ( $$ EQ NULL ) 
{ 

acmp_reason - ACMG SPACE; 
AC MPC ERROR; 

) 

> 

| locationid 

{$$=$1;} 

| shortid 

{$$=$!;} 

| LGDELID 

{ 

$$ a acmpalid ( &($!), 0, FALSE ); 

if( $$ EQ NULL ) 

{ 

acmp_reason = ACMG SPACE; 
ACMPCERROR; 

} 



t 
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} 



newlname 

: NAME longid 

{ $$ = $2; > 



news name 

: NAME shortid { $$ = $2; } 



nullrule 

: NOT NULLB 

| NOT NULLB WITH DEFAULT 
1 NULLB 



ownerparm 

: OWNER shortid { $$ = $2; } 



partsparm 

: NUM PARTS NUMBER 

{ 

$$ =* $2; 

CHKRANGE( $$, 0, ACMG_MAXPARTS, AC MG_PARTNO RANGE ); 

if ( acmp.reason ! = ACMG_RC_OK ) 

{ 

ACMPC ERROR; 

> 

} 



passwparm 

: DSETPASS ahortid { $$ « $2; } 

| NODSETPASS { $$ = NULL; } 



pctfreeparm 

: PCTFREE NUMBER 
{ 

$$ = $2; 

CHKRANGE( $$, 0, ACMG.MAXPCFR, ACMG_PCTFRANGE ); 
if ( acmp_reason t = ACMG_RC_OK ) 

{ 
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ACMPCERROR; 

} 



priqtyparm 

: PRIQTY NUMBER 
{ 

$$ = $2; 



CHKRANGEC $$, ACMG.MINPRQT. ACMG.MAXPRQT. ACMG PRQTRANGE 
if ( acmp, reason != ACMG_RC_OK ) 



{ 

ACMPCERROR; 

} 

} 



referencetb 

: REFERENCETB tb2name 



segparm 

: SEGSIZE NUMBER 
{ 

$$ = $2; 
{ 

if ( ($$ < ACMG_MINSEGSZ) 1 1 
t$$ > ACMG MAXSEGSZ) ) 

{ 

acmp_reason = ACMG_SEGSZERR; 
ACMPCERROR; 

} 

if(($$%4)!=0) 
{ 

acmp^reason = ACMG SEGSZERR; 
ACMPCERROR; 

> 

} 

} 



seqparm 

: SEQUENCE NUMBER 



secqtyparm 
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: SECQTY NUMBER 
{ 

$$ * = $2; 

CHKRANGEl $$. ACMG_MINSCQT» ACMG_MAXSCQT, AC MG.SCQT RANGE 

if < acmp_reason != ACMG_RC_OK ) 

C 

ACMPCERROR; 

} 



locationid 
: LOCID 

< 

$$ = acmpalid ( ACMG_LCTNID, TRUE ); 

if ( $$ EQ NULL ) 

{ 

acmp reason = ACMG_SPACE; 
ACMPCERROR; 

} 

} 



shortid 

: SHORTID 
{ 

$$ « acmpalid ( ACMG_SHORTIDLEN, TRUE ); 

if ( $$ EQ NULL ) 

{ 

acmp reason = ACMG_SPACE; 
ACMPCERROR; 

} 

} 

| SHDELID 
{ 

$$ a acmpalid ( &($l), ACMG_SHORTIDLEN, FALSE ); 

if C $$ EQ NULL ) 

{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 

} 

> 

| VOLSER 
< 

$$ = acmpalid ( &<$!>. ACMG_SHORTIDLEN, TRUE ); 
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if ( $$ EQ NULL ) 

{ 

acmp_reason = ACMG SPACE; 
ACMPCERROR; 

} 

} 



stogroupparm 

: STOGROUP shortid { $$ = $2; } 



stogroupname 

: shortid 

{ 

acmp_reason = acmpsgnmf $1, NULL, &acmpdata ); 
if ( acmp reason != ACMG RC OK ) 

{ 

ACMPCERROR; 

} 

} 



sub pages 

: SUBPAGES NUMBER 



tab le2 name 

: TABLE tb2name 



table3name 

: TABLE tb3name 
{ $$ = $2; } 



tbname2parm 
: NAME longid 



tb2naxne 

: shortid PERIOD longid 
{ 

$$ = acmgaloc { sizeoffstruct ACMP_TN) ); 
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if($$!=NULL> 
< 

$$->tbow = $1; 
$$->tbna = $3; 

} 

else 
{ 

acmp_reason = ACMG^SPACE; 
ACMPCERROR; 

} 

} 

| Iongid . 
{ 

$$ = acmgaloc ( sizeoftstruct ACMP_TN) ); 

if($$!=NULL> 

{ 

$$->tbna = $1; 

/• SET OWNER NAME TO GLOBAL AUTHID V 

$$->tbow s acmgaloc ( sizeofCVCHAR) + ACMG_SHORTIDLEN ); 

if ($$->tbow ! = NULL) 

{ 

acmpownr ( $$->tbow, &acmpdata ); 

} 

else 
{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 

} 

} 

else 
{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 

) 

} 



tb3name 

: locationid PERIOD shortid PERIOD longid 
{ 

$$ - acmgaloc ( sizeoftstruct ACMP_TN) ); 

if($$!=NULL) 

{ 

VCHAR •temp; 

/• REALLOCATE THE LOCATION PART OF NAME TO BE 16 BYTES*/ 
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temp a acmpalid < (struct ACMPJD •)$!, ACMG LCTNID, FALSE ); 
if ( temp ! = NULL ) 
( 

$$->tbloc - temp; 
acmgfree ( $$->tbloc ); 

} 

else 
{ 

acmp_ reason = ACMG SPACE; 
ACMPCERROR; 

} 

$$->tbow = $3; 
$$->tbna = $5; 

if ( memcmp ( acmpdata.Ioc, $$->tb!oc->data, 
$$->tbloc->len ) EQ 0 ) 

{ 

/• SET LOCATION TO BLANKS IF IT IS LOCAL V 
memset ( $$->tbIoc->data t * *, $$->tbIoc->len ); 

} 

} 

else 
{ 

acmpjreason = ACMG SPACE; 
ACMPCERROR; 

} 

} 

| shortid PERIOD shortid PERIOD longid 
{ 

$$ =s acmgaloc ( sizeofCatruct ACMP_TN) ); 
if($$!= NULL) 



VCHAR*temp; 

/• REALLOCATE THE LOCATION PART OF NAME TO BE 16 BYTES*/ 
temp = acmpalid ( (struct ACMP ID m )$l, ACMG LCTNID, FALSE ); 
if ( temp! » NULL ) 

{ 

$$->tbloc = temp; 
acmgfree ( $$->tbloc ); 

> 

else 
< 

acmp_reason = ACMG SPACE; 
ACMPCERROR; 

) 

$$->tbow = $3; 
$$->tbna = $5; 
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iff metncmp < acmpdata.loc, $$->tbloc->data, 
$$->tbloc->len ) EQ 0 ) 

{ 

/* SET LOCATION TO BLANKS IF IT IS LOCAL */ 
memset ( $$->tbloc->data, ' $$->tbloc->!en ); 

} 

\ 

else 
( 

acmp_ reason = ACMG_SPACE; 
ACMPCERROR; 

} 

) 

| tb2name 

{ 

/• SET LOCATION ID TO BLANKS V 

$$->tbloc acmgaloc ( sizeof(VCHAR) + ACMG_LCTNID ); 

if ($$->tbloc! = NULL) 

{ 

$$->tbioc->Ien = ACMG_LCTNID; 

memset ( $$->tbtoc->data t * ACMG LCTNID ); 

} 

else 
{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 

} 



sname 

: shortid PERIOD shortid 
{ 

acmp_reason = acmptnam( $3, $l t &acmpdata ); 
if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

> 

> 

| shortid 
{ 

VCHAR 'temp; 

temp - acmgaloc ( si zeo ft VCHAR) + ACMG_SHORTlDLEN ); 
if ( temp EQ NULL ) 

{ 
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acmp_reason = ACMG SPACE; 
ACMPCERROR; 

> 

temp->ien = ACMG_SHORTIDLEN - 1; 

memcpy ( &<temp->data>. ACMG_DEFDBNAM. ACMG SHORTIDLEN ); 
acmp_ reason = acmptnamt $1, temp, fcacmpdata ); 

if ( acmp_reason != ACMG RC OK) 

{ ' ~ 

ACMPCERROR; 

} 

} 



tsparm 

: TABLESPACE shortid 



type par m 
: datatype 



uniquerule 
m UNIQUE yesorno 



unit 

: K { $$ = ACMG_K; > . 

I CYL { $$ « ACMG CYL; } 

| TRK { $$ = ACMG~TRK; } 



validparm 

: NO VALIDPROC 
| VALIDPROC shortid 



vcatpaxms 

: VCAT shortid LPAREN vcatpaxmiist RPAREN 
{ 



/• ALLOCATE PARTS OBJECT •/ 

acmp_reason = acmpaloc ( ACMG^PTD, &acmpdata ); 

ift acmp reason EQ ACMG RC OK ) 

{ 

acmp_reason = acmpvcat( ACMG_PVD, $2, fcacmpdata ); 
if I acmp^reason != ACMG_RC_OK ) 
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{ 

ACMPC ERROR; 

> 

else 
{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 

> 

} 



vcatparmlist 
: vcatparm 

| vcatparmlist vcatparm 



vcatparm 

: VOLUMES LPAREN vollist RPAREN 

{ 

acmp_reason as acmpvIstC ACMG^PVD, 0, &acmpdata >; 

if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 

} 

} 

| UNITS unit 
{ 

acmp_reason = acmpunU $2 t &acmpdata ); 
if ( acmp_reason != ACMG_RC_OK ) 
{ 

ACMPCERROR; 

} 

> 

| PRIMARYVOLvolser 
{ 

acmp_retcode = acmpaloct ACMG^PVD, &acmpdata ); 

if ( acmp_retcode EQ ACMG_RC_OK ) 

{ 

/• CHECK IF PRIMARY VOLUME WAS ALREADY SPEC'D •/ 
if ( acmpdata.vcats->prvl[0] = = ' ' ) 

{ 

/• STORE PRIMARY VOLUME SPECIFICATION V 
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acmpvtn I acmpdata.vcats->prvl, $2 ); 

> 

else 
( 

acmp_reason = ACMG SPECERR; 
ACMPCERROR; 

} 

} 



| ORDERED yesorno 
{ 

acmp_retcode = acmpaloc( ACMG_PVD, fcacmpdata ); 

if ( acmp retcode EQ ACMG RC OK ) 

{ 

/• CHECK IF ORDER WAS ALREADY SPEC'D •/ 
if C acmpdata.vcat3->ordr EQ ACMG UNUSED ) 
{ 

/* STORE ORDER SPECIFICATION •/ 
acmpdata.vcats->ordr = $2; 

} 

else 
{ 

acmp_reason = ACMG SPECERR; 
ACMPCERROR; 

> 

} 



| vcatpass 

{ 

acmp_reason = acmpvps ( ACMGPVD, $1, fcacmpdata ); 

if ( acmp reason != ACMG RC OK ) 
{ 

ACMPCERROR; 

} 

) 



vcatpass 

: VCATPASS shortid 
| NOVCATPASS 



{ $$ = $2; > 
{ $$ = NULL; } 
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viewtext 

: AS SELECT QUOTEDSTR. 

vollist 
; volser 

{ 



a cmp_ reason = acmpvolst $1, &acmpdata ); 
if ( acmp_reason != ACMG_RC_OK ) 

{ 

ACMPCERROR; 



acmp_ reason = acmpvols( $3, &acmpdata ); 

if ( acmp_reason != ACMG_RC_OK) 

{ 

ACMPCERROR; 



volser 

: VOLSER 
{ 

$$ = acmpalid ( &($1), ACMG_VOLSERLEN. TRUE ); 

if($$ EQ NULL) 

{ 

acmp_reason = ACMG_SPACE; 
ACMPCERROR; 



| vollist COMMA volser 



yesorno 
: YES 
| NO 



{ $$ = ACMG_YES; } 
{ $$ = ACMG~NO; } 
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<?e<7 c 

SHORT ACMG DYN 
acmpcerror < SHORT lineno, 

SHORT reason, 

CHAR *s ) 

{ 

return ( acmperx ( lineno, reason, s ) ); 
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Claims 



20 1. A method of altering an existing data structure in a database system at an operating node of said 
database system, comprising the steps of: 

a) receiving from another node a change indication specifying changes to be made in the existing 
data structure; 

b) checking said existing data structure for compatibility with said changes to be made; 

25 c) if said changes to be made are compatible with said existing data structure, then making said 

changes, or else signalling an error. 

2. A method according to claim 1 wherein said change indication is in the format of a change definition 
language specified in accordance with Appendix A. 

30 

3. A method according to claim 1 wherein said data structure is defined by a catalog of tables, and said 
change definition language expresses changes to said data structure by changes to said catalog of 
tables. 



35 4. A method according to claim 3 wherein said catalog of tables is the lowest "object" level of said 
database system. 

5. A method according to claim 1 wherein said data structure includes tables, indexes and views, and said 
data structure is defined by a catalog including tables of tables, indexes and views. 

40 

6. A method according to claim 5 wherein said change indication is expressed in a change definition 
language for making changes in said catalog. 

7. Apparatus for altering an existing data structure in a database system at an operating node of said 
45 database system, comprising: 

a) means for receiving from another node a change indication specifying changes to be made in the 
existing data structure; 

b) means for checking said existing data structure for compatibility with said changes to be made; 

c) means for making said changes if said changes to be made are compatible with said existing data 
so structure, or, if not, signalling an error. 

8. Apparatus according to claim 7 wherein said qhange indication is in the format of a change definition 
language specified in accordance with Appendix A. 

55 9. Apparatus according to claim 7 wherein said data structure is defined by a catalog of tables, and said 
change definition language expresses changes to said data structure by changes to said catalog of 
tables. 
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10. Apparatus according to claim 9 wherein said catalog of tables is the lowest "object" level of said 
database system. , 

11. Apparatus according to claim 7 wherein said data structure includes tables, indexes and views, and 
said data structure is defined by a catalog including tables of tables, indexes and views. 

12. Apparatus according to claim 11 wherein said change indication is expressed in a change definition 
language for making changes in said catalog. 

13. Apparatus according to claim 12 wherein said node is one of a plurality of nodes of said system where 
changes to said database structure may be made. 

14. Apparatus according to claim 13 wherein said change indication is a batch file of statements in said 
change definition language. 

15. A method of altering an existing data structure in a database system at any one of a plurality of 
operating nodes of said database system, comprising the steps of: 

a) receiving at one of said nodes from another of said nodes a change indication specifying changes 
to be made in the existing data structure at said one of said nodes; 

b) checking said existing data structure at said one of said nodes for compatibility with said changes 
to be made; 

c) if said changes to be made are compatible with said existing data structure, making said changes, 
or, if not, signalling an error. 

16. A method according to claim 15 wherein said change indication is in the format of a change definition 
language specified in accordance with Appendix A. 

17. A method according to claim 16 wherein said data structure is defined by a catalog of tables, and said 
change definition language expresses changes to said data structure by changes to said catalog of 
tables. 

18. A method according to claim 17 wherein said catalog of tables is the lowest "object" level of said 
database system. 

19. A method of operating a computer system, comprising the steps of: 

generating and storing a data structure including a plurality of related tables of columns and rows 
of data values and indexes for said related tables to provide a relational database; 

generating and storing a catalog of definitions of said data structure including definitions of said 
tables and indexes and views of said tables and indexes; said definitions including a set of tables of 
said tables, columns and indexes; 

accessing said data structure and said catalog to provide a number of different views of data values 
in said data structure as defined by said catalog; 

said steps of generating and storing said data structure and said catalog and said step of accessing 
being specified by a user by statements in a structured query language to define said tables, indexes, 
catalog, and views; and 

altering said set of tables of said catalog to change at least some of said definition, in response to 
a set of statements of changes including statements for changing at least one of: 

a data specification of a column, 

the owner of a table, an index or a view, 

the name of a column, an index or a view. 
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20. A method according to claim 19 wherein said set of statements is selected from the statements of 
Appendix A. 

21. A method according to claim 19 wherein said structured query language is a special-purpose high-level 
5 programming language and said statements may be embedded in other different high-level program- 
ming languages and compiled to produce code for performing said steps of generating, storing and 
accessing. 

22. Apparatus for operating a computer system, comprising: 

10 

means for generating and storing a data structure including a plurality of related tables of columns 
and rows of data values and indexes for said related tables to provide a relational database; 

means for generating and storing a catalog of definitions of said data structure including tables 
75 defining said tables and indexes and views of said tables and indexes; 

means for accessing said data structure and said catalog to provide a number of different views 
and reports of data values in said data structure as defined by said catalog; 

20 said means for generating and storing said data structure and said catalog and said means for 

accessing being specified by a user by statements in a structured query language to define said tables, 
indexes, catalog, views and reports; and 

means for altering said catalog to change at least some of said definition including a set of selected 
25 change statements for changing at least one of: 

a data specification of a column, 

the owner of a table, an index or a view, 

30 

the name of a column, an index or a view, 
by changing said tables of said catalog. 
35 23. Apparatus according to claim 22 wherein said change statements are selected from Appendix A. 

24. Apparatus according to claim 22 wherein said structured query language is a special-purpose high-level 
programming language and said statements may be embedded in other different high-level program- 
ming languages and compiled to produce code for performing said steps of generating, storing and 

40 accessing. 

25. A method of generating a set of change statements for changing the definition of the data structure of a 
database; 

45 wherein said data structure includes a plurality of related tables of columns and rows and indexes 

for said related tables, and said definition is a catalog of said data structure including definitions of said 
tables and indexes and views of said tables and indexes, said catalog including a set of tables of said 
tables, columns and indexes; said catalog being specified by a user by statements in a data definition 
language to define said tables, indexes, and views; 

50 

comprising the steps of: 

selecting from a library of statements corhpatible with said data definition language a plurality of 
statements to change said, catalog to alter at least some of said definition including changing at least 
55 one of: 

a data specification of a column, 
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the owner of a table, an index or a view t 

i 

the name of a column, an index or a view, and 

5 comparing a representation of said plurality of statements to an existing instance of said catalog, 

and, if compatible with said existing instance, then generating said set of change statements. 

26. A method according to claim 25 wherein said plurality of statements includes a statement for adding a 
column to a view. 

10 

27. A program storage device readable by a machine, tangibly embodying a program of instructions 
executable by a machine to perform the method of claim 25. 

28. Apparatus for generating a set of change statements for changing the definition of the data structure of 
75 a database; 

wherein said data structure includes a plurality of related tables of columns and rows and indexes 
for said related tables, and said definition is a catalog of said data structure including definitions of said 
tables and indexes and views of said tables and indexes, said catalog including a set of tables of said 
20 tables, columns and indexes; said catalog being specified by a user by statements in a structured 
query language to define said tables, indexes, and views; 

comprising: 

25 a set of statements selected from a library of statements compatible with said structured query 

language to change said set of tables of said catalog to alter at least some of said definition including 
changing at least one of: 

a data specification of a column, 

30 

the owner of a table, an index or a view, or 

the name of a column, an index or a view. 

3$ 29. A method of describing a set of changes to an existing definition of a database, comprising the steps 
of: 

saving a copy of said existing definition; 

40 making a number of changes in said existing definition to produce a new definition of the database, 

generating a set of change requests describing said number of changes in a change definition 
language, by selecting from a library of statements to alter at least some of said definition including 
changing at least one of: 

a data specification of a column, 

the owner of a table, an index or a view, or 

so the name of a column, an index or a view. 

30. A method of describing a set of changes to an existing definition of a database, comprising the steps 
of: • 

55 saving a copy of said existing definition; 

making a number of changes in said existing definition to produce a new definition of the database, 
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generating a set of change requests describing said number of changes in a change definition 
language, by selecting from a library of statements as set forth in Appendix A. 

A method of making changes in a data description catalog of a database, comprising the steps of: 

a) receiving a list of change statements describing said changes, said change statements being 
selected from a library of change statements in the format of a change description language having 
a set of statements of changes including statements for changing: 

a data specification of a column, 

10 

the owner of a table, an index or a view, 

the name of a column, an index or a view; 

b) generating from said list a set of changes to said data description, said set of changes being in a 
75 standard data description language for said database. 

32. A method according to claim 31 wherein said database is DB2 and said data description language is 
SQL for DB2. 

20 33. Apparatus for making changes in a data description catalog of a database, comprising: 

a) means for receiving a list of change statements describing said changes, said change statements 
being selected from a library of change statements in the format of a change description language 
having a set of statements of changes including statements for changing: 

25 a data specification of a column, 

the owner of a table, an index or a view, 

the name of a column, an index or a view; 

30 

b) means for generating from said list a set of changes to said data description, said set of changes 
being in a standard data description language for said database. 
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© Change definition language for computer database system. 



© A database application implemented on a com- 
puter includes a generic database management 
product (software) such as IBM DB2 along with a 
catalog defining the way the data itself is stored. The 
catalog is a definition of the tables, indexes, views, 
user authorizations, etc., that specify a user's par- 
ticular application of the database management sys- 
tem. Access to the database via the catalog uses a 
structured query language or (SQL) which provides a 
way of expressing statements in a high-level lan- 
guage so the user will not be burdened with writing 
CO code to access the data itself. The structured query 
^ language provides statements for defining tables, 
^ indexes, views, etc., to be incorporated into the 
catalog. A database application (to fit a user's busi- 
ness) is generated and updated in a number of 
phases, such as design, development, test and pro- 
CO duction, and in each one of these phases a facility 
W exists for making alterations in the database defini- 
O tion (catalog), all of which make use of SQL to 
implement the changes. According to a feature of 
yj the invention, a change definition language (CDL) is 
provided which is an extension of (and in the general 
format of) the structured query language. The 



change definition language allows all important alter- 
ations to be described, as changes to an existing 
definition, for example, and may be used by all 
phases of the development cycle. The CDL state- 
ments do not make the changes directly in the 
catalog, but instead work through SQL and another 
intermediate mechanism such as DB2 ALTER tai- 
lored to make changes using SQL. The changes 
expressed in CDL may be migrated to downstream 
phases and fed back to earlier phases by use of a 
batch of change statements expressed in CDL. 
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